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ABSTRACT 


The purpose of this thesis is to provide a process model to assist organizations in analyzing their 
Wide Area Network communication lines. The Naval Medical Information Management Center 
(NMIMC), in Bethesda, Maryland, is used as the model site, due to its imminent deployment of World 
Wide Web (WWW) servers to Navy Medical Treatment Facilities (MTF’s). To model the typical MTF, 
an analysis of the data traffic transmitted from the existing WAN links managed and monitored by 
NMIMC will be performed. These WAN links are critical for the delivery of health care related 
information transmitted between MTF’s. The WAN links must be analyzed to ensure that adequate 
bandwidth is available to allow unobstructed traffic flow between destinations. The data traffic will be 
plotted to illustrate problematic conditions caused by high utilization rates. Corrective actions will be 
recommended that should help to reduce or eliminate the bottlenecks and increase network bandwidth, 
such as: load balancing, rightsizing of the WAN links, and increasing operational availability. The 
hypothesis is that the WWW servers should be installed after the WAN links are analyzed and either 
balanced or properly sized. The load balancing and rightsizing of the WAN links will ensure that 
adequate bandwidth is available for the proper and timely transmission and access of vital WWW server 
information. 
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1. INTRODUCTION 


A. PURPOSE 

The purpose of this research is to provide a process model to assist organizations, 
whether military or civilian, in analyzing their Wide Area Network (WAN) communication 
links. The main goal of this study is to ensure that proper bandwidth requirements are 
firmly incorporated prior to implementing a new network server into an existing network. 

The initial intention of this study was to assist the Naval Medical Information 
Management Center (NMIMC), located in Bethesda, Maryland, in developing 
implementation and deployment plans for their World Wide Web (WWW) servers. These 
servers are scheduled for deployment to Naval Medical Treatment Facilities (MTF), as 
directed by the Assistant Secretary of Defense, Health Affairs (ASD/HA). These 
directives are discussed in the background section below. However, upon further 
investigation, it became apparent that the main problem to be encountered with this 
initiative would be network data-trafBc bottlenecks and how to identify, reduce, or 
eliminate them. The analysis of NMIMC’s WAN links will model a typical Navy MTF. 

Therefore, the focal point of this thesis is to analyze the primary WAN links 
emanating from NMIMC. The data traffic will be plotted to illustrate problematic 
scenarios caused by high utilization rates. Recommendations offered to correct those 
problems will include corrective actions that will help balance the network traffic loads, 
and methods of rightsizing the WAN links. Various telecommunications services currently 
available in today’s marketplace will be also be addressed. 
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B. OBJECTIVES AND SCOPE 


This thesis will focus on analyzing NMIMC’s existing WAN links and the 
associated network data-trafiSc. The purpose of this analysis is to identify interesting 
trends, and to pinpoint distinct problems associated with the transmission of data. Specific 
issues such as the timing of transmission bursts and network traffic load will be 
researched. Some of these issues are greatly influenced by traffic congestion. The cause of 
the congestion, also known as a bottleneck, will be investigated. Certain problem 
resolutions will be presented to assist in reducing or eliminating these bottlenecks, and 
fi’eeing up precious network bandwidth. 

The hypothesis is that the WWW servers should be installed only after the WAN 
links are analyzed and properly sized. The rightsizing of the WAN links will ensure that 
adequate bandwidth is available for the proper and timely distribution and access of 
WWW server information. 

C. BACKGROUND 

1. Health Affairs Directives 

Information management at naval MTF’s is becoming increasingly important. To 
provide enhanced electronic information interchange within the Military Health Support 
System (MHSS), the Assistant Secretary of Defense for Health Affairs (ASD/HA) has 
initiated directives and guidelines for implementing a global information system utilizing 
the internet and the WWW. [Ref 1] 
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In support of this initiative, HA has agreed to fund the implementation and 
operation of a HA IntemetAVeb server, including hardware, software, contractor support 
regarding deployment issues, first year maintenance, and first year connectivity (T-1 
access to the internet). Funds will be transferred from HA to the three Services. Each 
Service then assumes the responsibility of fimding the implementation and operation of 
IntemetAVeb servers to support the electronic information interchange and web home 
pages that will allow complete interoperability across Health Affairs, the Surgeons 
General, and MTF’s. Life cycle management, as well as fimding for continued 
maintenance and internet access for the out-years, will be performed and provided by 
NMIMC. [Ref 2] 

2. Requirements 

Per HA directives, the requirements for implementing WWW servers to DoD 
agencies have been set [Ref 1]. Each agency, or service, is responsible for their 
implementation and deployment plans. The Naval Bureau of Medicine and Surgery 
(BUMED) has set the requirements for the Navy’s WWW Enhanced Electronic 
Information Interchange System, and has tasked NMIMC with the implementation and 
deployment plans [Ref 2]. More detailed information surrounding this request may be 
found in Appendix A. 

NMIMC was established to design, deploy, and support naval medical information 
management systems and telecommunications infrastructures. Therefore, the inherent 
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nature of NMIMC makes it uniquely qualified for the assigned task of deploying the 
Navy’s WWW servers. 

Questions revolving around the current and target infrastructure design, load 
balancing, WAN connectivity, bandwidth requirements, deployment, training, support, and 
maintenan ce are Still unresolved. The results of this research may assist in answering some 
of these questions and in formalizing the plans required to successfully deploy and 
implement this critical medical information requirement. 
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II. DATA COLLECTION AND CONVERSION 


A. PROBLEM DEFmmON 
1. NMIMC Site Visit 

A briefing between the author and key management personnel of NMIMC took 
place in an effort to arrive at the true nature of the problem surrounding the deployment of 
the WWW servers in support of the HA initiatives. In-depth discussions over the course 
of several days revealed the urgent requirement of ensuring proper bandwidth for the 
transmission of healthcare related data. The discussion quickly evolved into a WAN link 
capacity planning meeting. Existing WAN link capacity charts were reviewed, and 
recommendations for analyzing the links out of NMIMC were made. [Ref 3] 

The discussion then turned to the issue of how to estimate the growth pattern of 
the network traffic due to the installation of the WWW servers. While several good ideas 
were proposed, the discussion eventually became a stalemate, as no accurate methods of 
forecasting and projecting the growth pattern of network traffic were readily known. 

The nature of traffic growth due to the installation of WWW servers is extremely 
difficult to quantify and predict accurately without the proper equipment, resources, and 
time to properly justify the analysis. Since forecasting and predicting of both near and 
long-term growth of network traffic is difficult to determine, due to its various unknown 
variables, it is left as an exercise that must be further studied by NMIMC. The primary 
focus shifted to the existing network traffic, and how to analyze it and make 
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recommendations for rightsizing the WAN links and balancing the loads prior to the 
deployment of the web servers. 

2. Network Data-Traffic Review 

To fully understand the peculiar characteristics of the data traffic in question, a 
review of the incoming and outgoing network traffic was conducted. Several network 
managers and technical engineers were pooled to perform an initial review of the network 
traffic. The following data set is an example of the information that was generated as a 
result of taking a snapshot of the network traffic at a random point in time from the router 
in the computer room at NMIMC [Ref. 3]. This data set, seen in Figure 2.1, represents 
just one of the five links that are being anal 5 rzed; it was our first look at the data that was 
being collected and monitored by the router. The line numbers are not part of the data set, 
but are included for ease in fiiture referencing of the lines of code. 
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1. Fddi 0 is up, line protocol is up 

2. Hardware is cBus Fddi, address is aaOO.0400. Ic04 (bia 0000.Ocl8. Ie38) 

3. Description; FDDI Base Backbone 

4. Internet address is 131.158.100.8, subnet maskis 255.255.255.0 

5. MTU 4470 bytes, BW 100000 Kbit, DLY 100 usee, rely 255/255, load 1/255 

6. Encapsulation SNAP, loopback not set, keepalive not set 

7. ARP ^e: SNAP, ARP Timeout 4:00:00 

8. Phy-A state is active, neighbor is B, emt signal bits 008/20C, status ILS 

9. Phy-B state is active, neighbor is A, emt signal bits 20C/008, status ILS 

10. CFM is thru A, token rotation 5000 usee, ring operational IwOd 

11. Upstream neighbor 0000.0cl8.le3b, downstream neighbor aaOO.0400.1604 

12. Last input 0:00:00, output 0:00:00, output hang never 

13. Output queue 0/40, 0 drops; input queue 0/75, 0 drops 

14. Five minute input rate 66000 bits/sec, 34 packets/sec 

15. Five minute output rate 54000 bits/sec, 44 packets/sec 

16. 661479 packets input, 169499079 bytes, 0 no buffer 

17. Received 5722 broadcasts, 0 runts, 0 giants 

18. 34 input errors, 0 CRC, 34 frame, 0 overrun, 0 ignored, 0 abort 

19. 903492 packets output, 137036303 bytes, 0 underruns 

20. 0 output errors, 0 collisions, 0 interface resets, 0 restarts 

21. 0 transitions, 0 traces, 0 claims, 0 beacon 


Figure 2.1. Initial Data Set. From Re£[3]. 


B. CAPTURING NETWORK DATA-TRAFFIC 
1. Shell Programming 

Once the data traffic under review was fully understood, the next step was to 
figure out how to extract the relevant data so that it could be analyzed. The data that we 
were interested in is shown in lines 1, 5, 14, and 15 of the previous data set. Since the 
data generated by the router snapshot was discrete and repetitive, it was decided that shell 
programming in Unix would allow us a mechanism by which the relevant data could be 
captured. 
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The “shell” is the systems command interpreter. It reads each command you enter 
at your terminal and performs the operation that you called for. The shell is just an 
ordinary program that can be called by a Unix command. [Ref. 4] 

A mutual decision was made between the author and the network engineer to 
generate shell scripts that would take a sample of the data at 30 minute intervals, 24 hours 
a day, seven days a week, for at least two months. Obviously, in statistical analysis, the 
more samples (observations) taken, the more precise the calculations and inferences will 
be. Nevertheless, the observations for this study were intentionally limited to this time 
sequence in order to have sufficient time to analyze the data and complete this study. This 
random sampling should, however, generate a fairly accurate picture of the utilization 
rates of NMIMC’s five WAN links, and should show any potentially problematic peak 
utilization rates. 

The scripts were written in a Unix Bourne shell, version 3.2.2, and run on an 
AT&T 3B2 server. They are described in short detail in Appendbc B. 

2. Revised Data Set 

To clarify once again, we defined the data that we were interested in. The scripts 
pulled this data fi-om the original data set that was processed by the Cisco router. This 
revised data set, which is shown in Figure 2.2, presents the relevant data in a more 
meaningfiil format. The five data links are now represented in this new data set, which at 
this time becomes our primary file of interest. As indicated earlier, the numbers on the 
extreme left side are not actually part of the data set. They are provided so that it will be 



easy to refer to specific lines of the data set in explaining the meaning of the data in the 
following section. 


1 . .- ■ .. .-—..— 

2. Fri May 17 16:31:00 EDT 1996 

3. .. 

4. Serial 1 is up, line protocol is up 

5. MTU 1500 bytes, BW 56 Kbit, DLY 20000 usee, rely 255/255, load 13/255 

6. Five minute input rate 2000 bits/sec, 3 packets/sec 

7. Five minute output rate 3000 bits/sec, 3 packets/sec 

8. Serial 4 is up, line protocol is up 

9. MTU 1500 bytes, BW 56 Kbit, DLY 20000 usee, rely 255/255, load 150/255 

10. Five minute input rate 4000 bits/sec, 22 packets/sec 

11. Five minute output rate 33000 bits/sec, 22 packets/sec 

12. Serial 5 is up, line protocol is up 

13. MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, rely 255/255, load 1/255 

14. Five minute input rate 19000 bits/sec, 14 packets/sec 

15. Five minute output rate 5000 bits/sec, 6 packets/sec 

16. Serial 7 is up, line protocol is up 

17. MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usee, rely 255/255, load 1/255 

18. Five minute input rate 0 bits/sec, 1 packets/sec 

19. Five minute output rate 2000 bits/sec, 2 packets/sec 

20. Fddi 0 is up, line protocol is up 

21. MTU 4470 bytes, BW 100000 Kbit, DLY 100 usee, rely 255/255, load 1/255 

22. Five minute input rate 85000 bits/sec, 75 packets/sec 

23. Five minute output rate 83000 bits/sec, 81 packets/sec 


Figure 2.2. Revised Data Set. From Ref [3]. 


This revised data set is comprised of 23 lines of raw ASCII code that has been extracted 
firom the original data set that was taken firom the Cisco 7000 router [Ref 5]. This data 
set represents data-trafi5c statistics for the five WAN links coming out of NMIMC. The 
data for each link is described in four lines of code. Since the code is identical for each 
link, only lines 4-7 will be explained here. 
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On line 4, “Serial 1” is the identifier of the interface (link). Line 5 shows us MTU 
(maximum transmission units) in bj^es, the BW (bandwidth) of the connection, the DLY 
(delay) for the interface, the RELY (reliability) of the link, and the load. Lines 6 and 7 
show the five minute input and output rates, respectively, in both bits/second and 
packets/second. 

The sample data set shown above depicts the Serial 1 interface with a 100% 
reliability rate and a load of 13/255, or approximately 5 percent. The rely and the load are 
displayed as a percentage in which the denominator is 255. The load counter operates on 
an 8-bit value, thus the significance of the 255 denominator (11111111 in binary equals 
255). The load is computed by dividing the higher of the input or output rates by the BW. 
For example, the Serial 1 link has a BW of 56Kbit, an input rate of 2Kbits/second, and an 
output rate of 3Kbits/second. If you divide 3Kbits (the output rate) by 56Kbits, the result 
is 5.357%, which is displayed as a load of 13/255. All results are rounded down prior to 
displaying the load values. 

The termination points of the five links out of NMIMC are shown in Table 2.1. 
Figure 2.3 illustrates those links coming out of NMIMC, and their associated termination 
locations. 
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INTERFACE (Link) 

TERMINATION POINT (LOCATION) 

Serial 1 

Naval Medical Logistics Command, 

Fort Detrick, MD 

Serial 4 

NAVNET 

Serials 

Bureau of Medicine and Surgery 
(TPC/IP Traffic) 

Serial? 

Bureau of Medicine and Surgery 
(DEC LAT Traffic) 

FDDIO 

Fiber ring on Bethesda campus; connects Medical Center 
and Uniformed Services Universi^ of Health Sciences 
routers to the internet 


Table 2.1. Termination Points of NMIMC’s WAN Links. 



Figure 2.3. NMIMC WAN Link Sizes and Destinations. 
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3. Data Collection and Distribution 

The raw ASCII data that was captured from the Cisco router was immediately 
dumped into a separate ASCII text file, which was shown in the cron entry in Appendix B 
as /usr/dsc3cjc/trovini. Once enough data was acquired, it was transferred by the technical 
engineer at NMIMC to the author at the Naval Postgraduate School (NPS) by attaching 
the /usr/dsc3cjc/trovini data file to an email message. 

There was no specific cut-off time for the collection and transmission of the data; a 
random stopping point was chosen by the network technician who generated the script. 
Emails were generally received by the author from NMIMC once a week, typically at the 
end of the business week. It was feared that if the script was allowed to run and capture 
and dump the data for longer than a week at a time, the /user/dsc3cjc/trovini data file 
would be too large to transmit properly without incurring an occasional “time-out” error. ^ 

Once the data was transmitted, the /user/dsc3cjc/trovini file was emptied, and new 
data was captured for the next transmission. This iterative process was continued by the 
NMIMC network technician until the author deemed that enough data was captured to 
perform an accurate analysis of the existing traffic loads of the five WAN links. 


' This is somewhat of an insignificant fector, but is included as background information on the data 
collection process. This scheme may be of some value for those organizations that are contemplating 
performing their own network traffic analysis, and need to collect their data firom a remote source. 
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C. ANALYSIS OF NETWORK DATA-TRAFFIC 


1. Network Traffic FUe Generation 

Approximately 10 weeks worth of network trafi&c data was collected from 
NMIMC. Each transmission, or data dump, that was received from NMIMC was 
converted from the email message format into a separate file in the author’s home 
directory on the Unix server at NPS. The email header and signature data was stripped 
out of the message, and only the raw traffic data was saved as a new ASCII text file. The 
server platform used throughout this study consisted of a Sun workstation running Sun 
O.S. version 4.1.3. 

2. Initial Review of Captured Network Traffic 

The initial review of the pure traffic data consisted of a quick skimming of the load 
values as seen in lines 5, 9, 13, 17, and 21 of the revised data set. A portion of the first 
data file received was printed in order to expedite this first review; this hardcopy printout 
was used to highlight specific data. By using this printout, it was easier to identify the 
load values that were principally needed to study. The individual WAN link load values 
were reviewed specifically for extremely high utilization rates. It is these high utilization 
rates that are the main concern of this study and the foundation of this research. This 
basic review showed some peak load values, as well as those links that appeared to have 
the highest utilization rates. The next step was to determine how to extract that data from 
the revised data set. 
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3. SAS Script Generation 
a. Traffic Load File 


Once the preliminary review was completed, plans were made to extract 
the dates, the time of the observations, the link names, and the load values from the 
individual data files so that a statistical analyses could be performed on the data using the 
Statistical Analysis Software (SAS) application. That script, called trafiSc.sas, is presented 
in Appendix C [Ref 6], It computes the frequency distributions for the five links, the 
overall minimum and maximum utilization rates of the five links, and generates a 
breakdown chart showing the minimum and maximum utilization rates by hour. After the 
SAS scripts were written and tested on a small trafiBc data file, the individual traffic data 
files were concatenated into one file, and the overall SAS script was executed. Although 
this SAS script does not contain many lines of code, it is very powerful in what it 
accomplishes. A brief discussion of this SAS script is presented below to explain how the 
data was extracted from the raw data traffic. 

b. Traffic.sas Script Breakdown 

The idea behind the SAS script is very easy to understand. All the data 
found on the lines of code that are of interest from the revised data set must first be read 
into the SAS file. Once that has been done, all the data that is not of value is “dropped”, 
leaving only the relevant data to be acted upon. 

To read in the data, the individual words, or “chunks” of data on each line, 
which are separated by a space, must first be labeled. These individual chunks are 
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identified for data set lines # 2 , # 5 , # 9 , # 13 , #17, and #21. For example, line 2 of the data 
set, as seen below, displays the date and time information of a particular observation. 

#2. Fri May 17 16:31:00 EDT 1996 

The data chunks that need to be read in are day, month, date, and time of day, as shown in 
the following traffic, sas script segment. 


#2 
day $ 
month $ 
date $ 
tod$ 


Lines #5, #9, #13, #17, and #21 are fairly redundant, and all contain 13 chunks of data. 
All chunks are dropped except the last one, which defines the load value for that particular 
WAN link. As an example, the data chunks for line #5 are identified in table 2.2, where si 
is the SAS variable name assigned to the data chunk “MTU”, s2 is the SAS variable name 
assigned to data chunk “1500”, and so forth and so on. 


SAS 

Variable 

si 

s2 

s3 

s4 

s5 

s6 

s7 

s8 

s9 

slO 

sll 

sl2 

loadl 

Line #5 

Data 

Chunk 

MTU 

1500 

bytes, 

BW 

56 

Kbit, 

DLY 

20000 

usee. 

rely 

255/255, 

load 

13/255 


Table 2.2. SAS Variable Name Definitions. 
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All the values are dropped except the loadl value, which is the actual load rate, or 
utilization rate, for the seriall link. The other links loads are captured in the same way. If 
you look back to the beginning of the traffic, sas script, you will see where all the irrelevant 
data has been dropped. The only data that are being captured now are the specific dates, 
times, and load values for the five WAN links. Once the relevant data was filtered out 
fi’om the raw data, the traffic loads were then ready to import into a spreadsheet 
application for plotting. 
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III. DATA ANALYSIS AND REPRESENTATION 


A. VISUAL GRAPHICS 

Once the exact data to be analyzed had been captured, a method of illustrating the 
data in an easy to review format was needed. Since S AS does not adequately do justice to 
the graphing and plotting of data sets, the author chose Microsoft Word and Microsoft 
Excel to plot the graphs of traffic loads. This chosen format was thought to display the 
data in a manner that presents the clearest mental and visual image of the data traffic. 


B. A COMPARISON OF MEAN VS. MAXIMUM LOADS 
1. Mean Load Values 

The SAS traffic, sas program generated a chart that shows the mean load rates, the 
standard deviations, and the minimum and maximum load rates of the five WAN links 
under review. This chart is presented as Figure 3.1. These rate values were computed 
from data accumulated over the period of 23 April - 27 June, 1996. The details of the 
computations are described in Appendix D. 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

2359 

3.9325404 

10.6395563 

0.3921569 

98.0392157 

XLOAD4 

2359 

34.9420243 

23.3059572 

0.3921569 

100.0000000 

XLOAD5 

2359 

0.7138286 

1.1494338 

0.3921569 

28.6274510 

XLOAD7 

2359 

0.8830595 

5.1087385 

0.3921569 

98.0392157 

XLOADF 

2359 

0.3921569 

0 

0.3921569 

0.3921569 



Figure 3.1. Load Values. From Ref [6]. 
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There was approximately 60 days worth of data generated from the router scripts. Some 
of the data was lost due to a router upgrade on 23 May, when the Cisco AGS+ router was 
upgraded to a Cisco 7000 series router. This lost data is not expected to make much of an 
impact, if any, on the outcome of this study, as the values were all averaged over this 
observation period. There were 2,359 total observations performed on each of the five 
links. The observations are shown in Figure 3.1 under the variable “N”. The load 
variables, the mean load values, and the maximum load values were the data of interest, 
and are duplicated in Table 3.1. 


Link Name 

Variable Name 

Line Size 

Mean 

Maximum 

Serial 1 

XLOADl 

56 Kbps 

3.93 

98.0 

Serial4 

XLOAD4 

56 Kbps 

34.94 

100 

Serials 

XLOAD5 

T1 (1.544 Mbps) 

0.71 

28.6 

Serial? 

XLOAD7 

56 Kbps 

0.88 

98.0 

EDDIO 

XLOADF 

100 Mbps 

0.39 

0.39 

Table 3.1. Mean and N 

aximum Load Rates. 

After Re: 

f. [6]. 


Table 3.1 shows the mean load values and the maximum load values for each of the five 
WAN links being reviewed. The data contained in this table was used to generate the 
graphs of the mean and maximum load rates, which will hereafter be referred to as 
utilization rates. Figure 3.2 compares the mean utilization rates of the five links. 
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Mean Traffic Load 
(2359 observations per link) 



23 Apr - 27 Jun, 1996 


Figure 3.2. Mean Utili 2 ation Rates. 

This graphs clearly shows that the utilization rates of all 5 links are well below what the 
industry considers the maximum ceiling of 80%. [Ref 7] If we compare the rates against 
the capacity of the links, we can begin our interpretation of whether the links appear to be 
rightsized or not. Notice the high mean rate for XLOAD4. According to Table 3.1, 
XLOAD4 is identified as a 56Kbps line. The initial indication is that this link appears to 
be properly sized; however, the maximum load rates should also be examined to get a 
better indication of the variable traffic utilization rates. 

Table 3.1 also matches the variable names, such as XLOADl, to the link names, 
such as Seriall. Since the variable names and link names are used interchangeably through 
out this study, this table will help to reduce some of the confusion surrounding the 
naming conventions. The SAS scripts refer to the links as XLOADl, XLOAD4, 
XLOAD5, XLOAD7, and XLOADF, whUe the Unix scripts and router data sets refer to 
the links as Seriall, Serial4, SerialS, Serial7, and FDDIO. 
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2. Maximum Load Values 


To folly appreciate the value of the accumulated traffic data, you need to look 
beyond the mean rates to the maximum rates. The peak loads shown in Figure 3.3 are of 
great concern, because at those high rates data transmissions not only tend to slow down 
due to latency issues, but data packets may be lost once saturation of the line is reached if 
the buffers overflow. Generally, TCP will recovers this loss, which will be transparent to 
the user. What the user may notice is a slowing in responsiveness. Three of the five 
WAN links - Seriall, Serial4, and Serial? - are shown as exceeding the threshold level of 
80%. These links should undergo fiirther evaluation to determine the cause of the high 
rates. The type of data being transmitted and the time of day the transmissions occur 
should be looked at to uncover the reason for such a high rate. Plans to either balance the 
loads or rightsize the WAN links to a higher bandwidth should be implemented. Methods 
of load balancing and rightsizing of WAN links will be addressed in Chapter IV. 



Figure 3.3. Maximum Utilization Rates. 







C. GRAPHS AND CHARTS OF UTILIZATION RATES 


1. Houriy Utilization Rates 
a. Mean Load Graphs 

The SAS script traffic, sas generated hourly breakdown charts, showing the 
mean loads for each WAN link. Figures 3.4 through 3.8 illustrate the hourly trends of the 
five links. The data used to generate these graphs are provided in Appendix D. 

Figure 3.4 shows that the daily traffic for the Serial 1 link increases around the hour 
of 0600, where it remains fmrly stable until it begins a sharp drop between the hours of 
1500-1700. This would seem to indicate that the traffic load corresponds to normal 
business hours. All the traffic flowing over the five NMIMC links is IP traffic, such as 
Email and FTP [Ref 8]. The load rates seen in Figure 3.4 indicate that users are either 
checking their mail or transmitting files via FTP when they first arrive to work in the 
morning, again around lunch time, and finally, just before they go home in the afternoon. 
Although there are three distinct peaks seen for XLOADl, the low utilization rates, which 
vary between .58 and 9.42 percent, give a good indication that this link is not stressed and 
is properly sized. It is worth repeating that the values represented by these graphs are 
listed in Appendk D. 
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Figure 3.5 shows that the traffic pattern for the Serial4 link is similar to that of the Seriall 
link. The traffic takes a significant jump at 0600, remains fairly stable throughout the day, 
and begins to decline steadily at 1400. The noticeable peaks at 0600 and 1400 also follow 
a similar pattern noticed for the Seriall link. The traffic load for this link varies between 
18.3 and 48.9 percent. This is a significant increase from the rate seen for the Seriall link. 
This link should be looked at more closely to determine if it is in fact properly sized. We 
will be able to determine a more accurate indication when the maximum load rates are 
presented in the next section. 
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Figure 3.6 shows a trend that is similar in nature to the previous graphs. The traffic begins 
to increase around 0700, and begins to drop around 1400. Two distinct peaks occur at 
0900 and 1400. The traffic load for this link varies between .39 and 1.54 percent. At 
these low utilization rates the slight increases for this link would not be noticeable. 



Figure 3.7 shows an increase in utilization beginning at 0700, and tailing off just after 
1200. The peaks for this link occur at 1000 and 1200. The remaining times of the day 
show a very stable rate. The traffic load for this link varies between .39 and 2.83 percent. 
Again, at this low utilization rate, the increased usage at the peak times would not be 
noticed. 
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Serial? Link 


O 



Figure 3.7. Mean Utilization Rate, XLOAD7. 


The utilization rate shown in Figure 3.8 shows a steady rate throughout the day. This may 
seem like an error at first glance, however, this steady rate is due to the fact that the 
FDDIO link is a dual fiber optic link, running at 100Mbps capacity. At a rate of 0.4%, this 
means that no data transmissions were above 400Kbps. As discussed in Chapter H, the 
loads are computed by dividing the higher of the input or output rates by a divisor of 255. 
With the bandwidth set at 100 Mbps, and the input or output rate set at less than or equal 
to 400 Kbps, the load would be seen as a steady value of 1/255, or .4%, since this is the 
smallest value that can be represented. The FDDIO link provides the highest bandwidth of 
all the links at NMIMC. Refer back to Table 3.1 for a better indication of the orders of 
magnitude differences in the capacities of the links. This graph appears to indicate that 
there is a significant excess of bandwidth. However, the link is actually a dual fiber-optic 
cable, and the one time cost of installing this fiber is significantly less than the monthly 
recurring cost of a 56Kbps or higher communication line. Additionally, this link acts as 
the backbone for the campus network in Bethesda, MD. Had this been a T1 link, then the 
cost of providing this excess capacity would surely have to be justified. A chart showing 







some of the costs that NMIMC pays for their links is provided in Chapter IV. Therefore, 
a discussion of these costs will be deferred until then. 



b. Maximum Load Graphs 

Just as in the case for the mean loads discussed in the previous section, the 
SAS script traffic, sas generated hourly breakdown charts which show the maximum loads 
for each of the five NMIMC WAN links. Figures 3.9 through 3.15 illustrate the hourly 
trends of these links. The data used to generate these graphs are provided in Appendbc D 
along with the mean load data. Figure 3.9 shows peak loads for the Seriall link at 0600, 
1200, and 1500, with utilization rates of 98%, 94.5%, and 94.5% respectively. Since 
these peaks all exceed the 80% threshold, the Seriall link needs to be looked at to see if 
load balancing can alleviate its high utilization rate. 
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Figure 3.9. Peak Utilization Rate, XLOAD 1. 


Figure 3.10 indicates that this link peaks well above the 80% threshold during almost 
every hour of the day. In fact, it falls below the 80% threshold only once at 2300 with a 
utilization rate of 76.4%. Since this link is NMIMC’s only connection to the internet, the 
statistics indicate that it should be rightsized as soon as possible. 


Serial4 Link 

1CX) 

f “ 

5 60 

I 40 
I 20 
3 0 

Time of Day 


Figure 3.10. Peak Utilization Rate, XLOAD4. 
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Figure 3.11 shows a very pronounced peak at 0900. However, since this peak load has a 
utilization rate of just 28.6%, it appears that this link is properly sized, and no further 
action needs to be taken. However, the spike in the busy hour traffic may be smoothed by 
moving some of that traffic to non-peak times. 



Figure 3.11. Peak Utilization Rate, XLOAD5. 


The utilization rates seen in Figure 3.12 indicate an above threshold level between the 
hours of 0800 and 1200. The utilization rates vary during this period from 83.9% to 
98.0%. Load balancing may be able to smooth these peaks, and should be viewed as a 
possible corrective action. 
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Figure 3.12. Peak Utilization Rate, XLOAD7. 


The utilization rates of the FDDIO link, shown in Figure 3.13, show a steady rate of .39%. 
This is the same as the mean rate shown in Figure 3.8. It seems that this fiber link has a 
tremendous amount of excess capacity to satisfy both near term and long term traffic 
increases. 



Figure 3.13. Peak Utilization Rate, XLOADF. 
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2. Daily Utilization Rates 

a. Mean Load Gr(q>hs 

Figures 3.14 through 3.20 show that the only link that spikes throughout 
the week is XLOAD4. The highest spike occurs on Wednesdays, as seen in Figure 3.16. 
The utilization rate at that point is 39.2. The mean loads of the other links are extremely 
low, an indication that those WAN links are properly sized. 


Mondays' Mean Load 



_immmw p iBiamnaiiiMr , —■oonoBK , ■ nmnwMnfw- 1- mmmt m t r 

XLOAD1 XLOAD4 XLOAD5 XL0AD7 XLOADF 

NMlMC's WAN Links 


Figure 3.14. Average Load Per Link (Monday). 


Tuesdays' Mean Load 



XL0AD1 XL0AD4 XLOAD5 XL0AD7 XLOADF 


NMlMC's WAN Links 


Figure 3.15. Average Load Per Link (Tuesday). 
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Wednesdays' Mean Load 



XLOAD1 XLOAD4 XL0AD5 XL0AD7 XLOADF 

NMlMC's WAN Links 


Figure 3.16. Average Load Per Link (Wednesday). 



Figure 3.17. Average Load Per Link (Thursday). 
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Fridays' Mean Load 



Figure 3.18. Average Load Per Link Friday). 



Figure 3.19. Average Load Per Link (Saturday). 
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Figure 3.20. Average Load Per Link (Sunday). 


h. Maximum Load Graphs 

The maximum load utilization rates shown in Figures 3.21 through 3.27 
provide a different indication than the mean load rates. Figure 3.21 shows three links, 
XLOADl, XLOAD4, and XLOAD7 as having utilization rates that exceed the 80% 
threshold. Their load rates are 83.9%, 98%, and 98% respectively. 



XLOAD1 XLOAD4 XLOAD5 XLOAD7 XLOADF 


NMlMC's WAN Links 

Figure 3.21. Maximum Load Per Link (Monday). 
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Figure 3.22 is similar to the previous graph, except XLOAD7 drops from 98% to 56.8%. 
The utilization rates for XLOADl and XLOAD4 remain extremely high at 92.5% and 
98% respectively. 


Tuesdays' Maximum Load 
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Figure 3.22. Maximum Load Per Link (Tuesday). 


The utilization rates in Figures 3.23 through 3.25 are nearly identical, with XLOADl and 
XLOAD4 again nearly maxing out with utilization rates that fluctuate between 94.5% and 
100%. 
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Wednesdays' Maximum Load 
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Figure 3.23. Maximum Load Per Link (Wednesday). 


Thursdays' Maximum Load 



XLOAD1 XLOAD4 XLOAD6 XL0AD7 XLOADF 


NMlMC's WAN Links 


Figure 3.24. Maximum Load Per Link (Thursday). 
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Fridays' Maximum Load 



XL0AD1 XL0AD4 XL0AD6 XL0AD7 XLOADF 


NMlMC’s WAN Links 

Figure 3.25. Maximum Load Per Link (Friday). 


Figures 3.26 and 3.27 show the XLOADl rates dropping below 20%, while XLOAD4 
remains peaked at 92.5% and 94.5% respectively. 



Figure 3.26. Maximum Load Per Link (Saturday). 


35 





Sundays' Maximum Load 



XL0AD1 XL0AD4 XL0AD6 XL0AD7 XLOADF 
NMlMC's WAN Links 


Figure 221 . Maximum Load Per Link (Sunday). 

It is interesting to note that XLOAD4 was the only link that nearly attained the maximum 
value with spikes up to 100%. These graphs indicate the need to thoroughly review links 
XLOADl, XLOAD4, and XLOAD7. Plans to either balance the loads on those links or 
increase the size of the links need to be implemented immediately. These methodologies 
will be discussed briefly in Chapter IV. 

D. BENEFITS OF TREND ANALYSIS 
1. Needs Assessment 

The primary significance of analyzing the utilization rates is to help you assess your 
need to adjust your bandwidth requirements. The average rates, as illustrated in Figure 
3.2, do not provide an accurate measurement of the usage of the various WAN links. You 
must also identify the peak loads, as identified in Figure 3.3, and let the data tell you if you 
are properly positioned to provide the support necessary to handle your organizations 
traffic loads. If not, corrective actions must be taken to rightsize those links. 
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2. Down Time and Scheduled Maintenance 


An added benefit of perfonning an analysis of the hourly and daily utilization rates 
is the identification of low utilization periods. These lower usage periods are of significant 
value because they pinpoint times that can be used to the organization’s advantage. From 
an IT manager’s and system administrator’s point of view, these sags in utilization rates 
are an ideal time for scheduling down-time required to support periodic maintenance of 
systems, including mainfi-ames, routers, and other peripheral equipment. 

3. ReliabUity and AvaUability 

The data sets that were provided by the router, shown in Chapter n, show the 
reliability of the network links, as well as the traffic loads. Analyzing the statistics fi-om 
the network router can help you identify any degradation in the reliability of your network 
links. Less than perfect reliability rates impact the av^ability of your links, which in turn 
causes delays in data transmissions, and significantly decreases the support that you are 
able to offer your customers. Chapter VI discusses the meaning and the importance of 
operational availability, so details will be deferred until then. 
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IV. LOAD BALANCING AND RIGHTSIZING OF WAN LINKS 


A. PROBLEM ISOLATION AND RESOLUTION 

This chapter focuses on identifying, isolating, and solving problems that impede 
throughput performance in networks. In general, performance slowdowns are considered 
lower-priority problems than reachability issues. However, poorly performing 
internetworks can degrade organizational productivity and often can effectively halt 
operations of network applications if communications degenerates enough. Performance 
problems can reveal themselves in many ways. Slow host response, dropped cormections, 
latency, and high error counts all suggest that network performance is not optimal. 
Unfortunately, the actual sources of performance problems are often difficult to detect. 
[Ref 9] 

This chapter introduces an example problem-solving scenario that illustrates the 
process of problem isolation and resolution. Since certain common themes are present in 
most coimectivity problems, this chapter is provided in an effort to illustrate the use of 
troubleshooting tools and techniques to identify those common themes. [Ref 9]. 


B. METHODS OF LOAD BALANCING 
1. Redundant Links 

Remote bridges and routers often utilize load balancing, which is a uniform 
distribution of data over parallel links. These links can be similar or dissimilar. One link 
may have a transmission rate of 56 Kbps, while the other may be transmitting at 128 Kbps. 
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Generally, the network administrator will define the two links as a single logical link. The 
benefit of redundant links is that in the event the primary link goes down, the secondary 
link becomes active and allows the continued transmission of data packets throughout the 
network. [Ref 10] 

2. Improving Poor Performance Over A TCP/IP WAN 

a. Environment Description 

This section is concerned with performance in a TCP/IP internetwork 
featuring parallel serial links that join two geographically separated locations via IP 
routers^. This analysis focuses on isolating problems and then considering options for 
relieving congestion. 

Figure 4.1 shows the layout of the routers of the internetwork discussed in 
this example. The assumption is that the traffic to the main campus consists of FTP, 
Telnet, and E-mail^. For discussion purposes, we shall say that the users at Remote Site-A 
are comp laining about poor host response and slow performance when connecting to 
hosts at the main Campus. In addition, during certain times of the day, large files are 
being transferred over the serial network. At these times, the traffic becomes especially 
slow, but does not stop. 

The first thing to do is to identify all likely possible causes. The second 
step is to eliminate each one. The following problems are the most likely candidates for 
interconnection failure: 

* Any IP router will do; NMIMC uses Cisco routers. 

^ Another assumption is that Unix workstations are being used at the remote site. 
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• Overloaded server 

• Bad Ethernet or serial line 

• Congestion: 

1. at routers 

2. at servers 

3. on serial lines 

4. due to inappropriate WAN technology 

In an effort to keep this chapter concise, only a brief review of the 

highlights of these problem isolation processes is given. More detailed information 
regarding the process of problem isolation can be found by visiting various vendors’ home 
pages^. 


MAIN CAMPUS REMOTE SUE-A 



Figure 4.1. Dual 56 Kbps Serial Link TCP/IP Internet. After Ref [10]. 


^ Cisco’s home page can be found at URL http://www.cisco.com. The user can sign on as a guest, then go 
to the first page after the home page and select the hypertext link to Univer CD-ROM. An extensive index 
of Performance Problem Scenarios and associated problem isolation processes can be found there. 
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b. Problem Isolation 


The first thing to do is to determine the condition of the serial line. A 
preliminary check can be performed by using the ‘^how interfaces” command. The user 
should also check to see if input errors, output drops, or interface resets are high, as 
indicated in Figure 4.2, lines 8, 13, and 15. These conditions would indicate that the 
Serial-O line is overutilized. If the router reports that ‘Serial-0 is up, line protocol is up” 
you can assume that the serial line is functional, as well as the central office switches, 
intervening CSU/DSU, etc. The user should now perform a ‘t)ing” test to isolate the 
traffic bottleneck. This test should identify excessive packet drops, server failures , and 
time-out errors. Be sure to ping various nodes in the path, as seen in Figure 4.1, 
beginning with the router closest to the remote hosts, looking for the point at which drops 
start to occur. If those tests indicate no problems, ping between the routers. If these tests 
all pass, and you determine that the problem is indeed one of congestion due to bandwidth 
overutilization, you must then decide whether it is more effective to add bandwidth or to 
make an adjustment in the router configuration. [Ref. 9] 

If system administrators receive load values of about 50 percent, high input 
errors or output drops, they may consider implementing priority queuing to force Telnet 
to be given a higher precedence over other packet types. This helps ensure reasonable 
connection service to users, even during periods when file transfers are taking place. It is 
important to note that one reason why Telnet traffic can be bumped fi'om the buffer 
queues is the tendency of the larger FTP packet types to collect in the router’s buffers. 
When FTP traffic is high, the smaller Telnet packets are squeezed out of the input or 



output queues, resulting in retransmissions, session time-outs, and generally slower 
connection performance. By using priority queuing, marginal cases can be relieved. 

[Ref 9] 


1. Serial 0 is up, line protocol is up 

2. Hardware is MCI Serial 

3. Internet address is 131.158.100.8, subnet mask is 255.255.255.0 

4. MTU 1500 bytes, BW 56 Kbit, DLY 20000 usee, rely 255/255, load 1/255 

5. Encapsulation HDLC, loopback not set, keepalive set 

6. Last input 0:00:00, output 0:00:00, output hang never 
7 Last clearing of “show interface” counters never 

8. Output queue 0/40,78253 drops; input queue 0/75,0 drops 

9. Five minu te input rate 44000 bits/sec, 58 packets/sec 

10. Five minute output rate 41000 bits/sec, 49 packets/sec 

11. 4481625 packets input, 681913058 bytes, 19 no buffer 

12. Received 117015 broadcasts, 0 runts, 0 giants 

13. 1145 input errors, 160 CRC, 581 frame, 0 overrun, 0 ignored, 0 abort 

14. 5003523 packets ouq>ut, 2819930198 bytes, 0 underruns 

15. 0 ouq>ut enors, 0 collisions, 8631 interface resets, 

16. 15 carrier transitions 


Figure 4.2. Display Output of Show Interfaces Command. From Ref. [9]. 


If you are seeing load values close to 90 percent, as well as input errors 
and output drops, priority queuing is not likely to do any good. With consistently high 
congestion, you are better off adding new serial links, or increasing the size of your 
existing links. [Ref 9] 

In summary, the following problem resolution topics were discussed as 
being potential resolutions to performance problems in TCP/BP internetworks: 
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• Isolating problem nodes and eliminating potential problems using extended 
ping tests. 

• Determining when to tweak your configuration with priority queuing and when 
to add bandwidth 

• Specifying priory queuing to force the router to give a specific TCP/IP socket 
a higher priority than other protocols 


C. RIGHTSIZING THE WAN LINKS 

1. Data-Driven Decision Management 

Chapter m discussed the traffic flows of the WAN links under review. By 
continually analyzing their organizations WAN links, administrators will be in better 
position to rightsize their links before bottlenecks cause excessive delays and causes then- 
system to crash. Organizations should promote a data-driven decision management 
methodology, which stresses the use of historical data to assist managers in making 
strategic decisions regarding the networking needs of their customers/users. 

The graphs illustrated in chapter HI show the need to increase the size of several 
links. Table 4.1 shows the increase in bandwidth, and the associated recurring and non¬ 
recurring costs (NRC), proposed by NMIMC for several CONUS commands currently 
linked to the DISN NIPRNET. Of these, the increase in bandwidth associated with Naval 
Hospitals Great Lakes, Groton, Bremerton, and Pensacola are important. These four sites 
are scheduled to receive WWW servers in the near future. Are the proposed increases in 
bandwidth sufficient to satisfy the future load requirement placed on those communication 
lines by the increased traffic from WWW activity? It appears that they are, but the 
unknown variable in this assessment is the future traffic growth. 
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The cnix of this research has focused on analyzing the existing traffic loads of the 
WAN links at NMIMC. By analyzing today’s traffic loads, we can recommend 
appropriate sized lines to satisfy our current requirements. The missing link, however, is 
the future traffic growth placed on those links after the WWW servers are installed. By 
analyzing today’s needs and projecting future requirements, activities can then make 
recommendations for rightsizing their links accordingly. 


# 

Site Name 

Cuirent BW 

Current Cost 

NewBW 

New Cost 

Increase 

NRC Charge 

1 

NAVHOSP 

Bremerton 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

2 

NAVHOSP Camp 

Pendleton 

56K 

$1,875.00 


$8,635.00 

$6,760.00 

$5,000.00 

3 

NMC 

San Diego 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

1 

NAVHOSP 

Jacksonville 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

5 

NAVHOSP Camp 

Lejeune 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

6 

NMC Portsmouth 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

1 

NAVHOSP 

Pax River 

0 


256K 

$4,024.00 

$4,024.00 

$2,500.00 

8 

NNMC Bethesda 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

9 

NAVHOSP Groton 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

10 

NAVHOSP Great 

Lakes 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

Table 4.1. DISNNl 

DPKNET Bandwidth Increases and; 

Monthly Costs. From Ref [11]. 


45 






















































































2. Cost vs. Performance Trade-Off 


Before deciding to change the size of their communications lines, information 
managers need to evaluate their current trafiSc flows and let that data drive their decision 
as to what size link is the correct size for the organization. Additionally, managers need to 
check their budgets to see if they can afford the new link. The bottom line is that if they 
don’t install the correct sized links, the organization will not be operating as effectively or 
efficiently as it could be. Lost data due to incorrectly sized communication lines is not an 
economically acceptable practice. Organizations will lose their competitive advantage if 
their data does not flow in a timely fashion. 

Likewise, it is not acceptable for an organization to waste funds on installing a link 
that has excess capacity that will not be used for a year or two. To assist in making the 
right decision, a cost benefit analysis should be performed. This analysis should balance 
the funds available for communication lines against the right sized line to accomplish the 
mission. If you have the funds in your budget, it would be better to get a little extra 
capacity to ensure that the data will flow when the traffic loads spike. In reality, there is 
no such thing as ‘too much capacity”. If you can afford it, put in a bigger pipe, but be 
careful not to install a big pipe just for sake of having one. 

Table 4.2 shows the costs associated with various sized lines as provided by DISN, 
including the monthly recurring fees as well as the one-time installation costs. You will 
notice that the costs almost double from one size to the next. From this table it should be 
quite clear that the importance of rightsizing your organizations WAN links can result in a 
significant cost avoidance if done properly. 
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Rate 

Monthly Recurring 

Costs 

CONUS 

Monthly Recurring 

Costs 

EUROPE 

Monthly Recurring 

Costs 

PACMC 

Non Recurring 

Costs 

Ethernet 

$3,836.00 

$5,385.00 

$7,308.00 

$2,500.00 

9.6 Kb 

649.00 

884.00 

1,103.00 

2,500.00 

19.2 Kb 

1,066.00 

1,386.00 

1,813.00 

2,500.00 

56/64 Kb 

1,875.00 

2,437.00 

3,187.00 

2,500.00 

128 Kb 

2,747.00 

4,120.00 

5,768.00 

2,500.00 

256 Kb 

4,024.00 

6,035.00 

8,450.00 

2,500.00 

512 Kb 

5,895.00 

8,842.00 

12,379.00 

2,500.00 

1.544 Mb (T-1) 

8,635.00 

N/A 

N/A 

5,000.00 

2.048 Mb 

(OCONUS) 

N/A 

12,954.00 

12,954.00 

5,000.00 

1 

fable 4.2. 1996 Cost for DISN Service. From Ref [11] 
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V. HEALTH CARE TRENDS AND THE NECESSITY FOR 
GREATER BANDWIDTH 


A. TRENDS IN HEALTH CARE COMPUTING 

1. Information Systems Priorities 

The most important Information Systems (IS) Priorities for health care 
organizations are upgrading their IT infrastructures and integrating systems in a 
multivendor environment. Re-engineering to a patient-centered computing environment is 
also receiving priority attention from health care organizations. Figure 5.1 shows the 
breakdown of the IS priorities. The ratio between network and end systems was not 
available. The survey base was more heavily tilted toward the civilian sector, rather than 
the military, but applies to both nonetheless. [Ref 12] 


Miscellaneous 

18 % 


Re¬ 

engineering 

23% 



Upgrading iT 
Infrastructure 
32% 


Integrating 
Systems 
27% 

Figure 5.1. Greatest IS Priorities. From Ref [12]. 


Reflecting the larger trend in health care delivery, computer technology is 
distancing itself beyond the boundaries of the traditional hospitals environment. The two 
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largest departmental automation priorities for the upcoming year are physicians’ offices 
and outpatient clinics, far outpacing traditional inpatient settings such as critical care, OR, 
and Med/Surgery. [Ref. 12] 

In the outpatient setting, shown in Figure 5.2, the greatest advantage of IT is 
access to current patient information across the enterprise, essentially taking the care to 
the patients, rather than vice versa. Other advantages cited are: automating workflow; 
better financial management of offices; and better management of non-clinical patient 
tasks. 


Better of 
Nb>crncal 
MsceSaneous F^tiert Tasks 
7% 13% 



45% AUorrating 


WsrkflGW 

19% 


Figure 5.2. The Greatest Advantage of IT in an Outpatient 


Setting. From Ref [12]. 


2. The Internet and the World Wide Web in Health Care 

The revolution in cyberspace has reached health care. In a recent survey of trends 
in health care computing, more than 1,200 respondents provided their answers to 
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questions concerning the use of the Internet, the use of telemedicine, WWW home pages, 
and future uses of the Internet. 

Figure 5.3 shows the telemedicine commitment or those organizations surveyed. 
The chart shows that 76 percent of the organizations are either currently using this 
technology, or are actively investigating the use of it. 


No, but 

investigating it 
actively 
36% 


Yes, 

somew hat 
involved 
31% 



Not involved 
19% 


Other 

4% 


Yes, heavily 
Involved 
10 % 


Figure 5.3. Telemedicine Commitment. From Ref [12]. 


Those organizations that stated that they were either heavily involved or somewhat 
involved with telemedicine were asked, ‘How many network-based consultations has your 
organization conducted in the past year"? Those results are illustrated in Figure 5.4. It is 
interesting to note that 52 percent of those organizations conducted 200 or more 
telemedicine consultations per year. 
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Figure 5.4. Network-based Consultations 
Conducted in Past Year. From Ref. [12]. 


Continuing with the telemedicine technology, the using organizations were asked 
to select all the applications for which their organization was currently using or 
considering using from a preselected list. Those results are illustrated in Figure 5.5. 

Figure 5.6 shows the results of the question, ‘How is your organization currently 
using the Internet’? The numbers add up to more than 100 percent, because they were 
asked to choose all that apply. Only 19 percent of those surveyed said that their 
organization was not currently using the internet. This indicates the growing number of 
organizations who are getting connected to the internet in order to maint^ their 
competitive advantage in their profession. 
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Figure 5.6. Use of the Internet. From Ref. [12]. 
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Figure 5.7 shows the breakdown of those health care organizations that have a 
WWW home page, and the length of time they have been operational. The chart shows 
that 73 percent of those activities either have an active web page or are in the process of 
developing one. Again, this is a clear indication of the direction the health care industry is 
heading with regard to computer and information technology. 


No, but we 
are developing 
a site. 

36 % 


Yes, for less 
than a year. 
24 % 



No, no current 
plans to 
develop a site. 


Yes, for nrore 
than one year. 
13 % 


27 % 


Figure 5.7. Percentage of Active WWW Home Pages. 
From Ref [12]. 


Figure 5.8 illustrates the top futuristic health care technology that the participating 
organizations think will probably come into common use within the next five years. The 
use of the internet is clearly evident by the responses to this question, as 50 percent said 
either telemedicine from the home or medical records access via the internet would be 
introduced. 
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Complete Patient 
Records Kept on 
Smartcards 


Computerized 
Surgery, where 
a Patient is 
Operated on by 
a Surgeon from 
Another Location 
2 % 


Automated 
Pharmacies & 
Drug 

Disbursement 

14 % 


31% 



Rermte 

Diagnostics for 
Patients at Home 
(Telemedicine) 


Access to 
Medical Records 
via the Internet 


Other 27% 

3% 


23% 


Figure 5.8. Future Health Care Technology. 
From Ref. [12]. 


B. TARGET SYSTEM 

It is clear to see that the future of health care is going to be highly dependent on 
advanced technology. Hospitals, HMOs, and providers must embrace leading edge 
technology and apply it to their migration systems in order to be in position to provide the 
best health care to patients. One of the first steps health care facilities should take to 
ensure that their enterprise is functioning as effectively and efficiently as possible is to 
ensure that the bandwidth needed to transmit information - whether it is email, 
transmission of administrative or patient information via FTP, televideo conferencing, or 
telemedicine - is properly sized and available. By adopting a policy that requires your 
network administrator to perform a daily analysis of your network data traffic, you will be 
in a great position to ensure that your WAN links are rightsized and ready to support your 
users. 
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C. MILITARY ENVIRONMENT 


The results of the survey that generated the figures on the preceding pages are 
believed to be based on a predominantly civilian based population. However, the results 
can easily be mapped into the military community. The author believes that most of these 
trends are amplified in the military environment for the following reasons: 

• larger medical trainee population 

• larger percentage of remote patients 

• higher percentage of independent duty corpsmen 

• combat t 3 ^e injuries (higher puncture/shrapnel wounds and shock) vice civilian 
mix of casualties and ailments 

The assumption is that the trends displayed for the civilian sector are also appropriate for 
the miUtary. 
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VI. AVAILABILITY OF NETWORK LINKS 

A. AVAILABILITY HEURISTIC 

The trends in health care, shown in Chapter V, imply an ever increasing need for 
higher bandwidths and availability. High network availability can be defined as the 
likelihood that any given user can gain access to and successfully use the system at a given 
moment. It includes survivability and restorability in both peacetime and wartime 
emergencies, reliability of individual elements, physical redundancy, and a system design 
responsive to changes in network design and connectivity. [Ref 13] 

How critical and timely are your data transmissions? Are you dealing with time 
sensitive, life threatening issues that must be dealt with immediately? Can you afford to 
experience down time, and if so, how much? These are a few of the questions that you 
must answer to determine the level of availability that you are seeking for your 
organization. 

This chapter discusses the importance of Operational Availability, which in the 
engineering field is denoted as Ao [Ref 14], Ao is usually expressed as a percentage, and 
is defined as up time (total time minus down time) divided by total time. 

The primary means for achieving high availabihty consists of: [Ref 15] 

• design - installing or making use of redundant equipment and communications 
means so that backup alternatives are available when equipment fails 

• logistics - planning for component failures with management, backups, spare 
parts, and maintenance training 

• management - rapidly identifying and correcting malfunctioning equipment and 
bottlenecks 
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B. AVAILABILITY ENGINEERING MODEL 

1. Single-Threaded Model 

Figure 6.1 presents a model of a single-threaded network. The availability figures 
for these components may be obtained firom the vendors or suppliers, or may be estimated 
fi-om experience. The Ao of the individual components for our model are hypothetically 
set as follows: [Ref 14] 

• WAN (line) Ao = 99.7% 

• router Ao = 99.9% 

• LAN and end system Ao = 99% 



Figure 6.1. Single-Threaded System. 
After Ref [14]. 


In the field of applied statistics and probability, it is standard procedure to quantify 
the likelihood, or chance, that an event will occur. The likelihood of a particular outcome 








is quantified by assigning a number fi'om the interval [0,1] to the outcome (or a percentage 
fi-om 0 to 100%). The higher the number, the greater the chance of occurrence of that 
event. A zero indicates that an outcome will never occur, while a 1 indicates that an 
outcome will occur with certainty. [Ref 16] 

Since the three components in our model are wired in series, the Ao of the system 
can be expressed as the product of the three component values: 

Ao = 0.997x0.999x0.99 
= 0.986 

To put our model into perspective, the total time per month should first be computed, as 
seen in Figure 6.2. When you apply the above Ao value and monthly total time value to 
the Ao formula, you arrive at a monthly down time value of 605 minutes. This equates to 
approximately 10 hours of down time per month. 

Attempts to increase the Ao value of the components is limited to technology, i.e., 
solid state devices. Therefore, in order to obtain a greater availability, we must emulate 
our components and solve our Ao problems through redundancy. [Ref. 14] 
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60 min/hr 
X 24 hr/dav 
1,440 min/day 
X 30 davs/month 
43,200 min/month 

if Ao = up time/total time, 

where Ao = 0.986 

and 

total time = 43,200 min/mo, 
then 

0.986 = 43,200 - down time/43,200 
down time = 605 min/mo _ 

Figure 6.2. Calculation of Down Time. 


2. Redundancy Criteria 

a. Three Criteria of High Availability 

To assist you in maintaining the highest network availability as possible, the 
three principles of high availability engineering are hereby provided: [Ref 14] 

• eliminate single points of failure 

• provide reliable crossover (from primary to backup) 

• promptly detect & correct failures upon occurrence 


b. Eliminating Common Cause Failures 

A common cause failure is defined as a failure of one component that 
causes another component, typically the backup, to fail. By implementing engineering 
independence, we can eliminate common cause fdlures. An example would be placing 
individual computers within an organization on separate uninterruptable power supplies 
(UPS) so that the failure of one UPS will not cause aU the computers in the office to go 
down. Another example is to bring in telephone trunks (lines) into a command center 
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from more than one central ofiBce (CO). By using two different routes, you will avoid the 
vulnerability associated with a CO shut down, which could be caused by a jBre, or by the 
rupturing of buried cables. [Ref. 15] 

c. Reliable Crossover 

The changeover of a system from primary to backup mechanisms must be 
reliable. It simply is not acceptable to have the backup systems unavailable when they are 
needed. This criterion of high availability coincides with networking standards that tend 
to use all the cormectivity, both primary and backup, all the time. In addition to the 
efficiency gains (equipment and communications capacity not being idle), the reliability of 
the changeover mechanism is quite high as it is exercised continually in the course of 
normal business. Fortunately, this problem is handled quite nicely by the TCP/IP protocol 
stack for internetworks and by FDDI ring-wrap in LANs. [Ref 15] 

d. Detection of Failures Upon Occurrence 

Since high availability systems use backups, it is necessary to detect failures 
in primary equipment so that operations can be switched over to backups so that the 
primary equipment can be repaired before the backup equipment fails. Although the 
ability to rectify communications problems in a timely and efficient manner is important, it 
is more important to recognize potential problems before they occur and cause 
communication outages, excessive response times, or other types of impairments. This is 
the function of the network management process, which is defined as: [Ref 17] 
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...the process of using hardware and software by trained personnel to 
monitor the status of network components and line facilities, question end- 
users and carrier personnel, and implement or recommend actions to 
alleviate outages and/or improve communications performance as well as 
conduct administrative tasks associated with the operation of the network. 

By embracing the high availability principles, you can ensure that your organization is well 
positioned to deal with any potential network or communication problems that may occur. 
By m aintai ning a proactive, rather than a reactive posture, you will be in position to take 
action to conquer problems before they occur, or before they get out of control. 

3. Dual-Threaded Model 

Dual-threaded systems are the best way to eliminate single points of failure. As 
mentioned earlier, connectivity into the facility should be brought in via two separate 
central offices and through two different cable trenches or conduits. The routers should 
be cross-connected, protected with separate UPS units, and installed in different wiring 
closets, preferably in different buildings. Additionally, if the LANs are compatible, they 
should also be cross-coimected by installing a bridge. The ideal situation is one where one 
line failure can be compensated by the other, one router failure can be compensated by the 
other, and component failures in the LAN can be compensated by redundant workstations 
and LAN cabling. Figure 6.3 is a recalculation of the Ao presented in the single-threaded 
model. 
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Figure 6.3. Dual-Threaded System. After Ref. [14]. 


In this example, the Ao of the line remains 99.7%. This means that the probability of 
feUure is .3%, or 0.003. Since we now have two lines working together, either of which 
being up represents success, we then have a probability of failure of 0.003 x 0.003, or 
0.00009. This means that the line now has a combined Ao of 0.999991.^ By adding yet 
a third line, while maintaining independence of mode of failure, our model would have an 
Ao of 0.9999997. This graphically illustrates the importance of redundant lines. In 
summary, the procedure involves: 

• compute the probability of failure (1-Ao). 

• multiply the probabilities of failure for all parallel systems. 

• convert back to Ao by subtracting the probability of failure from 1. 


* When computing Ao, engineers count the number of “nines”. In this example, we have five “nines”. 
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This procedure should be performed on each module in the model, including the line, the 
router, and the LAN. In our model, shown in Figure 6.3, we get an Ao for the pair of 
routers of six ‘hines”, and for the cross-connected LANs we get an Ao of four ‘hines”. 
To compute the overall Ao for this system, we simply multiply the three Ao values as; 

Ao system = Ao WAN (line) x Ao routers x Ao LANs 
= 0.99999 X 0.999999 x 0.9999 
= 0.999889 

By using the same method and hypothetical component values illustrated in Figure 6.2, we 
compute the predicted down time and get about five minutes of down time per month. 
This is quite a dramatic difference fi’om the down time computed for the single-threaded 
system, the results due in large part to the redundancy concept. [Ref 14] 

C. FUNDAMENTAL COMPUTATIONS: THE SIGNIFICANCE OF Ao VALUES 

Although the values used for the models presented in this chapter are hypothetical, 
they are probably not too far fi'om realistic values. While the single-threaded system Ao 
of 0.986 may be acceptable for a typical office-automation environment, it is definitely not 
acceptable for mission critical environments such as C3I, combat, or medical. By 
eliminating the single points of failure, the Ao values shoot up to about four or five 
“nines”. [Ref 14] 

The difference in down time between systems that exhibit two ‘hines” versus four 
or five ‘hines” has been demonstrated. The bottom line is simple - plan on dual-threading 
your system. It provides the greatest availability possible. 




VII. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

1. Importance of Analyzing Data Traffic 

This research has shown the importance of anal 5 ?zing network data traffic. The 
main issue pertaining to the installation of the WWW servers was shown to be the 
bandwidth of the existing network WAN links, and whether or not the existing links were 
properly sized and able to support the traffic load placed on the network by the users. 
Data traffic from the five WAN links out of NMEMC was collected and analyzed. The 
incoming and outgoing traffic flows were reviewed, and the reliability of the lines were 
checked. The load values were analyzed, evaluated, and plotted. The data plots were 
quite graphical in the sense that they pointed out the importance of looking beyond the 
mean traffic load rates to the peak load rates. Spikes in the utilization rates were 
evaluated. Those lines that were shown to peak above the industry threshold of 80 
percent need to be properly sized prior to the implementation of the WWW servers onto 
the networks currently in place at the MTF’s. 

2 . Stay Current with Technological Changes 

Technology, as applied to the health care field, that involves the use of computers 
and information systems, continues to grow at a rapid pace. It is difficult to keep an 
organization running efficiently if administrators do not stay current with respect to the 
technology employed in their field. To offer an organization the best support possible, to 


67 



as many users as possible, administrators must be aware of the technology around them. 
They must evaluate the market leaders. They must stay abreast of the network 
communication services that both local and national providers have to offer, such as 
ISDN, Frame Relay, ATM, and ADSL, which are described in short detail in Appendix E. 
If administrators are current in their field, they are in excellent position to achieve 
successful changes for their organizations. Chapter V illustrated the direction that the 
health care field is heading with respect to computers, the internet, and the WWW. Those 
organizations that fail to stay current with the technological changes within their field will 
fall behind and lose their competitive advantage, and will not be able to provide the 
support they need to survive. 

3. Continual and Proactive Data Monitoring 

The process of analyzing your network traffic should be performed on a daily 
basis, rather than quarterly, or weekly. By keeping a constant pulse on network traffic 
utilization rates, organizations can ensure that they are positioned to make the necessary 
upgrades quickly, based on facts, and eliminate a lot of the guess work that they are 
currently faced with when trying to compute the bandwidth they really need to support 
their data flows. Organizations should adopt a data-driven decision management 
philosophy regarding the rightsizing of vital communication links; they should let the data 
assist them in making decisions regarding strategic positioning and rightsizing of their 
WAN links. Finally, by adopting a proactive, rather than reactive, policy on managing IT 
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assets, organizations can keep their vital information flowing, and provide the strategic 
advantage they need to yield the best support possible to their customers. 


B. RECOMMENDATIONS 

The evaluation of the WAN links at NMCMC is intended to be used as a model for 
all sites. This research lead to the following recommendations: 

• Deploy a network management platform to all MTF’s currently connected to 
the internet. 

• Train staffs in the use of the network management platform. 

• Perform load balancing at the sites that have redundant links. 

• Rightsize the individual links according to the need specifled by the data. 

• Implement data-driven decision management; let the data assist managers and 
network administrators in rightsizing the Wan links. 

• Investigate the possibility of transmitting FTP traffic during non-peak times. 

• Investigate the possibility of conserving internet bandwidth by caching hard-hit 
Home Pages or other popular pages. The caching can speed access and 
reduce the need to buy more internet bandwidth [Ref 26]. 

• Monitor network traffic on a daily basis. 

• Stay current with, technology. 

• Be proactive; analyze the network traffic and take action to eliminate problem 
areas before they cause network bottlenecks. 

• Challenge old paradigms; the technology is available to make sound changes, 
both technically and managerial, that assist administrators in maintaining the 
competitive advantage their organizations need to survive and thrive in their 
field. 


C. SUGGESTION FOR FURTHER RESEARCH 

Although this research is important to organizations in analyzing their WAN links, 
it falls short in providing a model for forecasting future traffic growth. Ideally, an 
enterprise network capacity plan should include potential changes and an anticipated 
traffic growth rate parameter. The author recommends using a network simulation 



planner, or application, to assist in this research. The equation for properly computing 
traffic growth should include current traffic loads plus anticipated traffic growth. This 
should ensure a more precise measurement of an organizations needs, and should better 
position an organization to provide the best support for their users, which in turn equates 
to a higher efficiency rating and success of the organization. 
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APPENDIX A. HEALTH AFFAIRS DIRECTIVES 

A. BACKGROUND 

In an effort to provide enhanced electronic information interchange (Eli) within 
the Military Health Support System (MHSS), the Assistant Secretary of Defense for 
Health Affairs (ASD/HA) has initiated guidelines for implementing a global information 
system utilizing the internet and the World Wide Web (WWW) [Ref. 1], 

In support of this initiative, ASD/HA has agreed to fund the deployment and 
operation of ASD/HA Internet /Web servers to various DoD MTFs. Funds will be 
transferred from HA to the three Services. Each Service then assumes the responsibihty 
of funding the design, implementation, and operation of Intemet/Web servers to support 
EH and web home pages that will allow complete interoperabihty across Health Affairs, 
the Surgeons General, and MTFs. [Ref 1] 

The Naval Medical Information Management Center (NMIMC), located in 
Bethesda, Maryland, was established to design, deploy, and support naval medical 
information management systems and telecommunications infrastructure. The inherent 
nature of NMIMC makes it uniquely qualified to accept the responsible for the assigned 
task of deploying the Navy’s WWW servers. 
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B. MISSION NEED STATEMENT 

The Bureau of Medicine and Surgery (BUMED) has embraced the use of the 
WWW technologies for the dissemination of information throughout the claimancy. It is 
crucial that Navy healthcare providers have access to the latest information on topics 
ranging from policy and administrative procedures to headquarters and MTF staffing 
rosters. 

The ASD/HA has initiated larger-scale programs to support Eli, however, 
BUMED has immediate information dissemination requirements and emerging technology 
management issues that must be addressed by NMCMC. The system proposed under the 
NMIMC abbreviated system decision paper (ASDP) will meet these requirements while 
allowing seemless interaction of Navy Medical home-pages with other MHSS components 
as directed by ASD/HA [Ref 2] 


C. TASKING 

NMIMC has been charged with design, deployment and support of Naval medical 
information systems and telecommunications infrastructure. The objective of the task 
statement (Statement of Work (SOW)) is to acquire support for the design, testing, 
implementation, installation, and training of the WWW system that is being deployed by 
NMIMC. 

The existing Navy Medical Department Network will be used as the infrastructure 
to support data transmissions from the WWW servers. This network is classified as a 
Wide Area Network (WAN), and was installed by a major effort know as the Medical 
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Open Architecture (MED-OA) Project. Figure A.1 shows the Metropolitan Area 
Networks that are in place to support Navy Medical administrative needs. 



Figure A.1. Navy Medical Department Network. 


Specific technical details surrounding this network will not be presented here, other than 
to say that the WAN links are of various bandwidths, ranging from 56Kb (56 thousand 
bits per second) to T-1 speeds (1.544 million bits per second). This is of importance to 
the WWW server acquisition initiative, as the bandwidth in many locations may not be 
appropriate for the anticipated increase in data traffic due to the addition of the WWW 
servers onto the existing network. These WAN links must be analyzed for data traffic 
flow and congestion, and rightsized as deemed necessary. This is perhaps the single most 
important technical aspect of this initiative, and is addressed in the statement of work. 
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The contractor shall perform all services prescribed in SOW at the tentative 
locations listed in Table A.1, which are subject to change at the discretion of NMIMC. 
[Ref 18] 


Server & Related Sites Listings 

Location 



1. NAVMEDINFOMGMTCEN 

Bethesda, MD 

2. Washington BUMED HQ 

Washington, DC 

3. NMQMC DET/East Coast MTFs 

Norfolk, VA 

4. NMIMC DETAVest Coast MTFs 

San Diego, CA 

5. Tricare Region Nine 

San Diego, CA 

6. Tricare Region Two 

Portsmouth, VA 

7. Great Lakes NH 

Chicago, IL 

8. Groton NH 

Groton, CT 

9. Bremerton, NH 

Seattle, WA 

10. Pensacola NH 

Pensacola, FL 


Table A.1. Projected WWW Server Locations. 


D. STATEMENT OF WORK FOR BUMED WWW SERVICES 

In an effort to be consistent with National Health Care Reform, the MHSS is 
embarking on a major program of health care reform called TRICARE. TRICARE is 
designed to ensure the most effective execution of the military care mission, recognizing 
the need to ensure access to a quality health care benefit, control cost, and respond to 
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chang ing national, military, and health care priorities. A major feature of TRICARE is the 
division of the United States-based MHSS into twelve Health Service Regions, each 
headed by a medical center commander designated as the Lead Agent, who has broad, 
new responsibilities for health care management throughout the region. The department 
of the Navy BUMED, the TRICARE Lead Agents, and MTFs have a critical need to be 
able to exchange and disseminate textual and graphical information concerning TRICARE 
policy, planning and execution, and medical information (including that which can be 
acquired from on-line sources such as Medline). [Ref 19] 


E. REQUIRED RESOURCES/SCOPE OF WORK 

The contractor has been requested to perform the following services: [Ref 20] 

• Develop Detailed Implementation Plan . The contractor shall develop a project 
plan that describes tasks, subtasks, and schedules; identifies members of the 
team, including areas of responsibility; and describes methods to be used to 
implement the project. The contractor will present a work breakdown 
structure providing detail regarding interim deliverables, resources, milestones, 
and schedule for the project. This plan may be modified as the tasks progress 
and the environment changes. It will be approved by the Task Monitor. 

• Implement WWW Home Pages . The contractor shall develop a WWW Home 
Page application for BUMED, NMIMC, Lead Agent Regions 2 and 9, and 
NMIMC Detachments in San Diego and Portsmouth, consistent with the 
guidelines developed by Health Affairs. Continuous user feedback will be a 
critical part of the development effort. The home pages and each subsequent 
pages A^l be fielded for ‘beta” testing within NMIMC before release to the 
internet. 

• Conduct Hvper-Text Markup Language tHTML^ Conversion , The contractor 
shall convert key documents into HTML. It is assumed that all documents will 
be in an industry standard word processing format, i.e. WordPerfect, Microsoft 
Word, ASCn, etc. The number of documents and the extent to which each 
document will contain ‘hyper-links” will be dependent on the period of 
performance. 
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Specific tasks to be provided by the contractor include: [Ref. 19] 

• Conduct Site Surveys 

• Develop detailed implementation plan 

• PPP/SLIP server configuration 

• Implement WWW Home Pages 

• Conduct Hyper-Text Markup Language (HTML) Conversion 

• Design Target System 

• Develop Support/Training Plan 

• Domain Name Service (DNS) Upgrade Study 

• Deploy Servers 

• Conduct Training 

• Develop USENET Plan 

• Implement USENET Capabilities 

• Deploy Browsers 

• Operate and Maintain Home Pages 


Specific deliverables to be provided by the contractor include: [Ref 19] 

• Detailed Implementation Plan 

• Communication Upgrade Study 

• BUMED WWW Home Pages 

• Key Documents in HTML Format 

• Target System Specifications 

• Support/Training Plan 

• Training Material and Documentation 

• Site Survey Reports 

• USENET Plan 

• Operation and Maintenance Home Pages 


F. CONTRACT VEHICLE 

Initially, the proposed systems were planned on being acquired via the following 
procurement options, where feasible: 

• GSA Schedule 

• Existing Procurement Contracts 

• Open Market 

• A combination of the above options 
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Where those options are not available, or where high tech or highly specialized items are 
required but not available on existing contracts, procurement will be accomplished 
through the establishment of an 8(a) contractor. [Ref 2] 

The contract vehicle that happened to be available to NMIMC was the 
D/SIDDOMS contract. The acronym stands for Defense Medical Information 
Systems/Systems Integration, Design, Development, Operations, and Maintenance. This 
contract is dated 10 March, 1996, and is managed by the United States Army’s Defense 
Medical Program Activity managers, who are based in Skyline, Virginia. The Initiating 
Proponent is the Office of the Assistant Secretary of Defense for Health Affairs. [Ref 21] 
The Contracting Agency for the Army is the Defense Supply Service, Washington 
DC. There are approximately 600 support personnel assigned in various satellite offices, 
including the Pentagon, who handle all task orders and support for this contract. [Ref 21] 
The D/SIDDOMS contract is also a provider of components for one of the DoDs 
major projects, the Composite Health Care Systems project, which provides numerous 
services such as patient appointments and scheduling, patient administration, and email 
service to various MTF departments. Other major Navy projects that are using the 
D/SIDDOMS contract vehicle include [Ref 21]: 

• Systems Integration Project 

• Automated Information Security Project 

• Telemedicine Project 
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The D/SIDDOMS is a follow-on contract to the SIDDOMS, which ran for 6-7 years prior 
to the signing of the new contract. The type of equipment and services offered by the 
D/SIDDOMS contract are vast, and include any IT related elements such as: 

• Hardware 

• Software 

• Planning and Development 
.• Prototyping 

• Support Services 

• Maintenance 

There are three lots available on the D/SIDDOMS contract [Ref 21]. They are listed as: 

• Loti 

- System Design, Development, Operations, Maintenance, and Support 

- Contractors include: AMS, EDS, PRC, SAIC 

- Ceiling is $325M 

• Lot n 

- Systems Integration, Oversight, Requirements Development, Concept 
Development 

- Contractor: Northrop Grumman 

- Ceiling is $50M 

• Lot in 

- Studies and Analysis 

- Contractors: Birch and Davis, Solon Consulting, United Health Care, 

Vector Research 

- Ceiling is $25M 

• POC for Lot I & H: Ms. JuUe Phillips (703) 681-6903 

• POC for Lot in: Ms. Brenda Mabrey (703)681-8720 [Ref 22] 
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The authors’ understanding is that the D/SIDDOMS contract is a Requirements Contract, 
which is defiined as; 

A requirements contract provides for filling all actual purchase requirements of 
designated government activities for specific supplies or services during a specified 
contract period, with deliveries to be scheduled by placing orders with the 
contractor. This type is used when the government anticipates recurring 
requirements, but can not predetermine the precise quantities of supplies or 
services that will be needed during a definite period. Funds are obligated by each 
delivery order, not by the contract itself [Ref 23] 

The NMIMC proposal is to procure the following components fi'om the D/SIDDOMS 

contract [Ref 8]: 

• Hardware, i.e., WWW servers 

• Software, i.e., web browser(s) 

• Labor, to include: 

1. Deployment 

2. Communication lines/WAN analysis 

3. Cisco router administration/management 

4. User training 

5. Maintenance 

6. System Support 


G. PROPOSED SOLUTION 

The proposed solution is to design, engineer, procure, test, deploy, and operate a 
WWW server suite at NMIMC that supports the BUMED Headquarters, NMIMC, and 
the Washington DC region. Similar installations will be performed at the NMIMC 
Detachments to support both the Eastern and Western regions. The WWW servers will 
support home pages and administrative systems for BUMED, NMIMC, and other MTFs. 
The system will support interfaces to on-line medical resources like Medline, organize and 
index medical resources on the Internet, and provide workgroup tools for information 
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sharing among functional groups. Enhanced Internet connectivity will be provided to each 
site as required to support the increased network trafihc anticipated with the introduction 
of the WWW service. This solution will allow system components to be managed from 
NMIMC network management systems. Additionally, the proposed solution will 
incorporate a facility to manage access to systems with restricted access and to control 
access to the Internet at large. [Ref 2] 

Selected systems will use commercial-off-the-shelf (COTS) hardware and 
software. Advanced functionality will require some software customization. The 
emphasis of this system is not on software development, but on providing the platform, 
structure, tools, and management support for individuals and organizations throughout the 
claimancy to easily maintain information content and build additional functionality. 

[Ref 2] 

H. ALTERNATIVES CONSIDERED 

1. Maintaining the Status Quo 

This alternative will not provide the EH capabilities dictated by ASD/HA and will 
not address the information dissemination requirements of BUMED, NMIMC, and the 
MTFs. Therefore, this alternative is deemed unacceptable. [Ref 2] 
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2. Central Claimancy Master Server Implementation 

This solution would locate all system resources in a single location, rather than 
distributing systems across major regions. A central solution would cost less but is not 
desirable for the following reasons: 

• loss of local ownership would impact local information sharing and reduce the 
usefulness of the system 

• single point of failure and loss of service redundancy 

• communications requirements and Internet connectivity overly taxing oat 
central host location 

It should be noted that some degree of centralization is achieved under the proposed 
solution, primarily by having claimancy-wide standards and an organized methodology for 
information sharing and dissemination. [Ref 2] 


L COSTS AND BENEFITS 

The life cycle cost of the alternatives are described below [Ref 2]. 

a. Maintaining the Status Quo. This option is not shown since it is not an 
acceptable alternative as it fails to meet mission requirements. 

b. Central Claimancy Master Server Implementation. 

The life cycle costs of the alternative centralized solution are shown in Table A.2. 
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COSTS: ($0,000) 

FY96 

FY97 

FY98 

FY99 

FYOO 

TOTAL 

SYSTEM HW&SW 

$500 

$30 

$0 

$0 

$0 

$530 

Installation & Maintenance 

190 

45 

45 

45 

45 

370 

Operations 

600 

600 

450 

450 

400 

2500 

Total ($0,000) 

$1290 

$675 

$495 

$495 

$445 

$3400 


Table A.2. Life Cycle Costs of Centralized Solution. From Ref [2]. 


c. Proposed Solution 

The life cycle costs of the proposed BTJMED/NMIMC solution are shown in Table 


A.3. 

Costs assumptions are based on [Ref 2]; 

• 2 high capacity WWW production servers and 1 development server (35K per) 

• 2 high capacity WWW production multimedia and application link servers and 1 
development server (15K per) 

• software for the above servers includes development and monitoring tools, and 
database/application interface software (75K) 

• Installation, operational support and other personnel, WWW expertise for 
server/communications installation and ongoing operations, and programming and 
design are all outsourced. Each of the four production systems are assumed to require 
5K of installation and approximately lOK of operational support per year 
(development systems require 5K of installation and 5K of operational support per 
year). Programming and design support is assumed to be 35K per server in the initial 
2 years, tapering down in the out years. 
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Costs: ($0,000) 

FY96 

FY97 

FY98 

FY99 

FYOO 

Total 

System Servers 

150 

0 

0 

0 

0 

150 

Server Software 

75 

0 

10 

0 

10 

95 

Conuns Hardware 

40 

0 

0 

0 

0 

40 

Maintenance 

0 

10 

10 

10 

10 

40 

Supplies 

3 

3 

3 

3 

3 

15 

Installation 

25 

0 

0 

0 

0 

25 

Training 

8 

15 

10 

0 

0 

33 

Hardware Upgrade 

8 

15 

25 

20 

10 

78 

Software Upgrade 

0 

12 

20 

15 

10 

57 

Site Prep 

20 

0 

0 

0 

0 

20 

Internet Comms 

55 

55 

45 

45 

40 

240 

Operational 

45 

50 

50 

35 

35 

215 

Personnel 

140 

140 

no 

50 

50 

490 

Total ($0,000) 

569 

300 

283 

178 

168 

1498 


Table A. 3. Life Cycle Costs of Proposed Solution. From Ref [2]. 


J. BENEFITS OF PROPOSED SOLUTION 

Electronic information interchange within BUMED will meet the goals of 
optimizing communications flow and will meet the requirements for connectivity within 
MHSS as dictated by ASD/HA. The regional approach to WWW server deployment will 
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maximize the local control and therefore, maximize the use and benefits of the technology 
while mini mizing central support costs. pRef 2] 


Additionally, the claimancy will benefit from improved decision making due to 
higher quality information being delivered to the appropriate decision maker when and 
where needed. The claimancy will also benefit firom increased availability of training and 
readiness resources, which will help develop better prepared decision makers. Improving 
the preparedness and capabilities of Navy medical decision makers will result in higher 
quality health care delivered to the customer. [Ref 2] 


K FUNDING ISSUES 

The author had the distinct pleasure of meeting Major Fred Peters, USAF, at the 
American Academy of Medical Administrators (AAMA) conference that was held in 
Irvine, CA, in November, 1995. Major Peters is the Chief of Operations for Defense 
Medical Information Management, Office of the ASD/HA. He presented a briefing for the 
AAMA regarding the status of Health Affairs Information Systems. Afterwards, the 
author and Major Peters briefly discussed the issues surrounding this thesis - which deal 
with analyzing the WAN links at NMIMC - since it is directly tied to the WWW server 
implementation plan. During this conversation. Major Peters stated that the funding for 
the WWW server components would be provided by the ASD/HA. He further explained 
that ASD/HA would transfer the fimds, via a Military Inter-service Procurement 
Requirement (MDPR), to the individual DoD agents, who in turn would be responsible for 
procuring their own components for the WWW server project. 



In January, 1996, the author again had the fortune of meeting Major Peters at the 
Healthcare Information Management Systems Society (HEMSS) conference in Atlanta, 
Georgia. The ensuing discussion centered around the MIPR, and Major Peters confirmed 
that the MIPR action had already taken place between the ASD/HA and the Services. 

Therefore, once the components ordered on the individual delivery orders are 
received by the Navy MTFs and the invoices are certified, payment will be made by 
NMIMC fi-om the funds MDPRed fi-om the ASD/HA and earmarked for the WWW server 
initiative. 
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APPENDIX B. UNIX SCRIPTS 


A. CRON ENTRY 

The cron entry is also known as a daemon process. A daemon is a process that 
executes ‘in the background” either waiting for some event to occur, or waiting to 
perform some specified task on a periodic basis. The cron entry is a standard Unix 
process that performs periodic tasks at given times during the day, taking its instructions 
from the file/usr/lib/crontab. The cron entry shown below defines when the data is to be 
sampled. In our case, the data was requested every 30 minutes. [Ref 24] 

cron entry: 

/usr/dsc3cjc/testl | egrep '(=|EDTlprotocollMTU|minute)' 

/usr/dsc3cjc/trovini 

This script basically performs an iterative process at the specified time interval. The shell 
goes to the /usr/dsc3cjc/testl script, performs that function, and returns to the cron script. 

The remaining portion of the cron entry uses pipes (j) and the egrep command to 
perform specific operations on the data prior to dumping the results into the 
/usr/dsc3cjc/trovini file. 

Pipes allow you to connect two commands together so the output firom one 
program becomes the input of the next command. The egrep command is simply an 
extended version of the grep command. The grep command means “globally search for a 
regular expression and print all lines containing it. A regular expression combines a 
string of text with some special characters used for pattern matching. Therefore, the grep 
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is used within the pipe so that only those lines of the input files containing a given string 
are sent to the standard output. [Ref 4] 

For more information about Unix commands, you should refer to any Unix book 
or manual. More detailed explanations at this point would just cloud the issue, and you 
need to stay focused on the basic process here, which is leading up to the plotting of the 
traffic-data, or more specifically, the utilization rates. 


B. TBDE TESTl SCRIPT 

After the time sequencing is assigned, the shell goes to the 
/usr/dsc3cjc/testl file. The testl script is shown below. 


testl: 

echo" . " 

date 
echo" 

telnet < /usr/dsc3cjc/tn.cmd & 
sleep 15 
kill -9 $! 


Once in testl, the process is told to echo (regenerate) the ‘^==“ lines that surround the 
date. This command prints the lines onto the screen, allowing the time to stand-out from 
the other data to make it easier to distinguish the time intervals. After the testl script 
echoes the second ‘^=“ line, the shell telnets into the /usr/dsc3cjc/tn.cmd script, where it 


performs that operation, and returns to the testl script. 



The ampersand (&) is used to specify a background process. It allows the kernel 
(the operating system nucleus), the program in charge of the Unix system, to synchronize 
two or more processes running concurrently. By using the &, you are telling the kernel to 
execute a command while the login shell is doing something else. [Ref. 25] 

In our case, that something else is sleeping for 15 seconds so that the telnet session 
can run. Once the tn.cmd is done, the kill -9 command kills the background shell (telnet 
session). The $! variable is used to hold the process ID (PID) of the last process run in 
the background; it is used to notify the shell which process to kill. 

C. THE TN.CMD SCRIPT 

As mentioned earlier, after the testl script echoes the second ‘^==“ line, 

the shell telnets into the /usr/dsc3cjc/tn.cmd script, which is shown below. This sidestep 

simply opens a session with the 131.158.50.50 device, which is the Cisco 7000 router, and 

asks it to show the interfaces of the five WAN links. The “~q” command tells the tn.cmd 

script to exit and returns to the testl script. The ‘kros” command is the super-secret 

mystery password that the technical engineer uses to gain access to the router. 

tn.cmd: 

escape 

open 131.158.50.50 
aros 

sho int serial 4/1 , 

sho int serial 4/4 

sho int serial 4/5 

sho int serial 4/7 

sho int fddi 2/0 

~q 
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APPENDIX C. SAS SCRIPT 


Chapter n introduced the SAS script that was generated to extract the dates and time of 
the observations, the link names, and the load values from the individual data files so that a 
statistical analysis could be performed on the data. The following script was written to 
accomplish that goal [Ref 6], 


options linesize=80; 

filename kevin '/h/josliua_u3/kltrovin/tliesis/cat.dat'; 

data one (drop= si s2 s3 s4 s5 s6 s7 s8 s9 slO sll sl2 five 

dl d2 d3 d4 d5 d6 d7 d8 d9 dlO dll dl2 

el e2 e3 e4 e5 e6 e7 e8 e9 elO ell el2 

fl f2 f3 f4 £5 f6 f7 f8 f9 no fll fl2 

gl g2 g3 g4 g5 g6 g7 g8 g9 glO gll gl2); 

infile kevin; 


input 


#2 


day$ 

months 

dates 

todS 


#5 


#9 



s5S 

slOS 

Sis 

s6 S 

sllS 

s2S 

s7S 

sl2S 

s3S 

s8 S 

loadl S 

s4S 

s9S 



d5S 

dlOS 

dlS 

d6S 

dllS 

d2S 

d7S 

dl2S 

d3S 

d8S 

load4 S 

d4S 

d9S 
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#13 


el$ 
e2$ 
e3 $ 
e4$ 


e5$ 

elO$ 

e6 $ 

ell$ 

e7$ 

el2$ 

eS $ 

loads $ 

e9$ 



#17 

fl$ 
f2$ 
f3 $ 
f4$ 


f5$ 

flO$ 

f6$ 

fll$ 

f7$ 

fl2$ 

fS$ 

load7 $ 

f9$ 



gl$ 

g2$ 

g3$ 


g4$ 

g9$ 

g5$ 

gio$ 

g6$ 

gll$ 

g7$ 

gl2$ 

g8$ 

loadfddiS 


#23 five $; 



nloadl= length(loadl); 
iiload4= length(load4); 
nload5= length(load5); 
iiload7= length^oad?); 
nloadf= length(loadfddi); 

array nload{5} nloadl iiload4 nload5 nload? nloadf; 
array xload{5} xloadl xload4 xloadS xload? xloadf; 
array load{5} loadl load4 loads load? loadfddi; 

do i = 1 to 5; 

if iiload{i}= 5 then xload{i}=(substr(load{i},l,l)/255*100); 
else if nload{i} = 6 then ?doad{i}=(substr(load{i},l,2)/255*100); 
else if nload{i}=7 then xload{i}=(substr(load{i},l,3)/255*100); 
else xload{i}=-999; 
end; 

hour = sobstr(tod,l,2); 

proc freq; tables xloadl xload4 xloadS xload? xloadf; 
proc means; 

var xloadl xload4 xloadS xload? xloadf; 
proc sort; by hour; 
proc means; 

var xloadl xload4 xloadS xload? xloadf; 
by hour. 
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APPENDIX D. SAS DATA CHARTS 


Chapter IQ introduced the SAS charts that where generated from the traffic, sas 
program [Ref. 6], These charts show the frequency distributions and the hourly mean, 
standard deviation, minimum load values, and maximum load values for the five NMIMC 
WAN links analyzed in this study. These charts are provided in this appendk for 
informational and reference purposes. The values in these charts were used to generate 
the graphs introduced in chapter IQ that show the trends of the data traffic for the WAN 
links. 


Cumulative 


XLOADl 

Frequency 

Percent 

Frequency 

Percent 

0.3921568627 

1359 

57.6 

1359 

57.6 

0.7843137255 

4 

0.2 

1363 

57.8 

1.1764705882 

2 

0.1 

1365 

57.9 

1.568627451 

413 

17.5 

1778 

75.4 

3.137254902 

2 

0.1 

1780 

75.5 

3.5294117647 

149 

6.3 

1929 

81.8 

5.0980392157 

87 

3.7 

2016 

85.5 

7.0588235294 

64 

2.7 

2080 

88.2 

8.6274509804 

53 

2.2 

2133 

90.4 

10.588235294 

40 

1.7 

2173 

92.1 

12.156862745 

20 
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2193 

93.0 

14.117647059 

27 

1.1 

2220 

94.1 

15.68627451 

19 

0.8 

2239 

94.9 

17.647058824 

15 

0.6 

2254 

95.5 

19.607843137 

12 

0.5 

2266 

96.1 

21.176470588 

13 

0.6 

2279 

96.6 

23.137254902 

6 

0.3 

2285 

96.9 

24.705882353 

6 

0.3 

2291 

97.1 

26.666666667 

3 

0.1 

2294 

97.2 

28.235294118 

5 

0.2 

2299 

97.5 

30.196078431 

3 

0.1 

2302 

97.6 

31.764705882 

4 

0.2 

2306 

97.8 

33.725490196 

5 

0.2 

2311 

98.0 

35.68627451 

2 

0.1 

2313 

98.1 

37.254901961 

3 

0.1 

2316 

98.2 

39.215686275 

1 

0.0 

2317 

98.2 

40.784313725 

1 

0.0 

2318 

98.3 




47.843137255 

4 

0.2 

2327 

98.6 

49.803921569 

1 

0.0 

2328 

98.7 

53.333333333 

1 

0.0 

2329 

98.7 

56.862745098 

3 

0.1 

2332 

98.9 

62.352941176 

1 

0.0 

2333 

98.9 

65.882352941 

2 

0.1 

2335 

99.0 

67.843137255 

1 

0.0 

2336 

99.0 

69.411764706 

1 

0.0 

2337 

99.1 

71.37254902 

3 

0.1 

2340 

99.2 

74.901960784 

1 

0.0 

2341 

99.2 

80 

2 

0.1 

2343 

99.3 

81.960784314 

1 

0.0 

2344 

99.4 

83.921568627 

1 

0.0 

2345 

99.4 

85.490196078 

2 

0.1 

2347 

99.5 

87.450980392 

2 

0.1 

2349 

99.6 

90.980392157 

2 

0.1 

2351 

99.7 

92.549019608 

1 

0.0 

2352 

99.7 

94.509803922 

3 
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2355 

99.8 

96.078431373 

3 

0.1 
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98.039215686 

1 
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Cumulative 


XLOAD4 

Frequency 

Percent 

Frequency 

Percent 

0.3921568627 

148 

6.3 

148 

6.3 

1.568627451 

118 

5.0 

266 

11.3 

3.5294117647 

74 

3.1 

340 

14.4 

5.0980392157 

54 

2.3 

394 

16.7 

7.0588235294 

31 

1.3 

425 

18.0 

8.6274509804 

27 

1.1 

452 

19.2 

10.588235294 

16 

0.7 

468 

19.8 

12.156862745 

15 

0.6 

483 

20.5 

14.117647059 

14 

0.6 

497 

21.1 

15.68627451 

23 

1.0 

520 

22.0 

17.647058824 

19 

0.8 

539 

22.8 

19.607843137 

32 

1.4 

571 

24.2 

21.176470588 

36 

1.5 

607 

25.7 

23.137254902 

59 

2.5 

666 

28.2 

24.705882353 

71 

3.0 

737 

31.2 

26.666666667 

76 

3.2 

813 

34.5 

28.235294118 

93 

3.9 

906 

38.4 

30.196078431 

113 

4.8 

1019 

43.2 

31.764705882 

127 

5.4 

1146 

48.6 

33.725490196 

113 

4.8 

1259 

53.4 

35.68627451 

107 

4.5 

1366 

57.9 

37.254901961 

88 

3.7 

1454 

61.6 

39.215686275 

84 

3.6 

1538 

65.2 

40.784313725 

73 

3.1 

1611 

68.3 

42.745098039 

61 

2.6 

1672 

70.9 
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44.31372549 

55 

2.3 

1727 

73.2 

46.274509804 

44 

1.9 

1771 

75.1 

47.843137255 

50 

2.1 

1821 

77.2 

49.803921569 

29 

1.2 

1850 

78.4 

51.764705882 

35 

1.5 

1885 

79.9 

53.333333333 

31 

1.3 

1916 

81.2 

55.294117647 

33 

1.4 

1949 

82.6 

56.862745098 

29 

1.2 

1978 

83.8 

58.823529412 

28 

1.2 

2006 

85.0 

60.392156863 

32 

1.4 

2038 

86.4 

62.352941176 

30 

1.3 

2068 

87.7 

63.921568627 

31 

1.3 

2099 

89.0 

65.882352941 

20 

0.8 

2119 

89.8 

67.843137255 

21 

0.9 

2140 

90.7 

69.411764706 

19 

0.8 

2159 

91.5 

71.37254902 

16 

0.7 

2175 

92.2 

72.941176471 

15 

0.6 

2190 

92.8 

74.901960784 

14 

0.6 

2204 

93.4 

76.470588235 

7 

0.3 

2211 

93.7 

78.431372549 

12 

0.5 

2223 

94.2 

80 

17 

0.7 

2240 

95.0 

81.960784314 

17 

0.7 

2257 

95.7 

83.921568627 

12 

0.5 

2269 

96.2 

85.490196078 

8 

0.3 

2277 

96.5 

87.450980392 

8 

0.3 

2285 

96.9 

89.019607843 

9 

0.4 

2294 

97.2 

90.980392157 

13 

0.6 

2307 

97.8 

92.549019608 

16 

0.7 

2323 

98.5 

94.509803922 

16 

0.7 

2339 

99.2 

96.078431373 

15 

0.6 

2354 

99.8 

98.039215686 

4 

0.2 

2358 

100.0 

100 

1 

0.0 

2359 

100.0 


Cumidative 


XLOAD5 

Frequency 

Percent 

Frequency 

Percent 

0.3921568627 

1927 

81.7 

1927 

81.7 

0.7843137255 

120 

5.1 

2047 

86.8 

1.1764705882 

81 

3.4 

2128 

90.2 

1.568627451 

61 

2.6 

2189 

92.8 

1.9607843137 

24 

1.0 

2213 

93.8 

2.3529411765 

30 

1.3 

2243 

95.1 

2.7450980392 

30 

1.3 

2273 

96.4 

3.137254902 

18 

0.8 

2291 

97.1 

3.5294117647 

17 

0.7 

2308 

97.8 

3.9215686275 

8 

0.3 

2316 

98.2 

4.3137254902 

6 

0.3 

2322 

98.4 

4.7058823529 

6 

0.3 

2328 

98.7 

5.0980392157 

6 

0.3 

2334 

98.9 
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5.4901960784 

3 

0.1 

2337 

99.1 

6.2745098039 

4 

0.2 

2341 

99.2 

6.6666666667 

3 

0.1 

2344 

99.4 

7.0588235294 

3 

0.1 

2347 

99.5 

7.4509803922 

3 

0.1 

2350 

99.6 

8.2352941176 

1 

0.0 

2351 

99.7 

8.6274509804 

2 

0.1 

2353 

99.7 

9.0196078431 

3 

0.1 

2356 

99.9 

9.4117647059 

1 

0.0 

2357 

99.9 

14.901960784 

1 

0.0 

2358 

100.0 

28.62745098 

1 

0.0 

2359 

100.0 


Cumulative 


XLOAD7 

Frequency 

Percent 

Frequency 

Percent 

0.3921568627 

2019 

85.6 

2019 

85.6 

0.7843137255 

111 

4.7 

2130 

90.3 

1.1764705882 

56 

2.4 

2186 

92.7 

1.568627451 

90 

3.8 

2276 

96.5 

1.9607843137 

29 

1.2 

2305 

97.7 

2.3529411765 

16 

0.7 

2321 

98.4 

2.7450980392 

13 

0.6 

2334 

98.9 

3.137254902 

7 

0.3 

2341 

99.2 

3.5294117647 

4 

0.2 

2345 

99.4 

8.6274509804 

1 

0.0 

2346 

99.4 

24.705882353 

1 

0.0 

2347 

99.5 

30.196078431 

1 

0.0 

2348 

99.5 

31.764705882 

1 

0.0 

2349 

99.6 

39.215686275 

2 

0.1 

2351 

99.7 

47.843137255 

1 

0.0 

2352 

99.7 

56.862745098 

1 

0.0 

2353 

99.7 

83.921568627 

1 

0.0 

2354 

99.8 

85.490196078 

1 

0.0 

2355 

99.8 

90.980392157 

1 

0.0 

2356 

99.9 

96.078431373 

1 

0.0 

2357 

99.9 

98.039215686 

2 

0.1 

2359 

100.0 


Cumulative 

XLOADF Frequency Percent Frequency Percent 


0.3921568627 2359 100.0 2359 100.0 
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Variable 


N 


Mean 


Std Dev Minimum Maximum 


XLOADl 

2359 

3.9325404 

10.6395563 

0.3921569 

98.0392157 

XLOAD4 

2359 

34.9420243 

23.3059572 

0.3921569 

100.0000000 

XLOAD5 

2359 

0.7138286 

1.1494338 

0.3921569 

28.6274510 

XLOAD7 

2359 

0.8830595 

5.1087385 

0.3921569 

98.0392157 

XLOADF 

2359 

0.3921569 

0 

0.3921569 

0.3921569 


HOUR=00 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

95 

1.1351909 

2.5437021 

0.3921569 

21.1764706 

XLOAD4 

95 

21.9855521 

20.5044732 

0.3921569 

92.5490196 

XLOAD5 

95 

0.3962848 

0.0402344 

0.3921569 

0.7843137 

XLOAD7 

95 

0.3962848 

0.0402344 

0.3921569 

0.7843137 

XLOADF 

95 

0.3921569 

0 

0.3921569 

0.3921569 


HOUR=01 


Variable 

N 

Mean 

Std Dev Minimum 

Maximum 

XLOADl 

96 

0.8537582 

1.2150467 

0.3921569 

10.5882353 

XLOAD4 

96 

28.0269608 

21.0668687 

0.3921569 

87.4509804 

XLOAD5 

96 

0.3921569 

0 

0.3921569 

0.3921569 

XLOAD7 

96 

0.4370915 

0.2119083 

0.3921569 

1.5686275 

XLOADF 

96 

0.3921569 

0 

0.3921569 

0.3921569 


HOUR=02 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

98 

0.7402961 

0.6939737 

0.3921569 

3.5294118 

XLOAD4 

98 

36.6986795 

21.4577464 

0.3921569 

90.9803922 

XLOAD5 

98 

0.3921569 

0 

0.3921569 

0.3921569 

XLOAD7 

98 

0.4161665 

0.1671987 

0.3921569 

1.5686275 

XLOADF 

98 

0.3921569 

0 

0.3921569 

0.3921569 


HOUR=03 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

98 

0.7202881 

0.6388044 

0.3921569 

3.5294118 

XLOAD4 

98 

37.8591437 

20.3488966 

0.3921569 

94.5098039 

XLOAD5 

98 

0.3961585 

0.0396138 

0.3921569 

0.7843137 

XLOAD7 

98 

0.4241697 

0.1751379 

0.3921569 

1.5686275 

XLOADF 

98 

0.3921569 

0 

0.3921569 

0.3921569 
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HOUR=04 ~ 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

96 

0.5882353 

0.4407463 

0.3921569 

1.5686275 

XLOAD4 

96 

28.0596405 

16.7210665 

0.3921569 

92.5490196 

XLOAD5 

96 

0.4003268 

0.0563043 

0.3921569 

0.7843137 

XLOAD7 

96 

0.4044118 

0.1200730 

0.3921569 

1.5686275 

XLOADF 

96 

0.3921569 

0 

0.3921569 

0.3921569 


-HOUR=05 — 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

97 

0.7802709 

0.9205509 

0.3921569 

5.0980392 

XLOAD4 

97 

27.9482515 

16.4354897 

0.3921569 

81.9607843 

XLOAD5 

97 

0.3961997 

0.0398175 

0.3921569 

0.7843137 

XLOAD7 

97 

0.4164140 

0.1364875 

0.3921569 

1.5686275 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 


-HOl]R=06- 

Variable N Mean Std Dev Minimvim Maximum 

XLOADl 96 8.6437908 24.9907353 0.3921569 98.0392157 

XLOAD4 96 46.2500000 23.2802642 0.3921569 98.0392157 

XLOAD5 96 0.4656863 0.2500531 0.3921569 1.5686275 

XLOAD7 96 0.4738562 0.3639679 0.3921569 3.5294118 

XLOADF 96 0.3921569 0 0.3921569 0.3921569 


-HOUR=07- 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

95 

5.6842105 

12.6953393 

0.3921569 

96.0784314 

XLOAD4 

95 

35.9133127 

20.0593473 

0.3921569 

96.0784314 

XLOAD5 

95 

0.6150671 

0.6563351 

0.3921569 

5.0980392 

XLOAD7 

95 

0.5696594 

0.5684862 

0.3921569 

3.5294118 

XLOADF 

95 

0.3921569 

0 

0.3921569 

0.3921569 


-HOUR=08- 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

98 

7.2589036 

14.7691511 

0.3921569 

87.4509804 

XLOAD4 

98 

43.5174070 

25.5061109 

0.3921569 

96.0784314 

XLOAD5 

98 

1.2404962 

1.8069370 

0.3921569 

8.2352941 

XLOAD7 

98 

1.5726291 

9.8540855 

0.3921569 

98.0392157 

XLOADF 

98 

0.3921569 

0 

0.3921569 

0.3921569 
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HOUR=09 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

100 

6.7686275 

11.3621797 

0.3921569 

71.3725490 

XLOAD4 

100 

40.9019608 

23.1422226 

0.3921569 

96.0784314 

XLOAD5 

100 

1.5411765 

3.3117707 

0.3921569 

28.6274510 

XLOAD7 

100 

1.7803922 

9.0230379 

0.3921569 

85.4901961 

XLOADF 

100 

0.3921569 

0 

0.3921569 

0.3921569 


HOUR=10 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

97 

6.5130382 

11.2360179 

0.3921569 

85.4901961 

XLOAD4 

97 

38.8356580 

21.5497878 

1.5686275 

98.0392157 

XLOAD5 

97 

0.9096422 

1.0597708 

0.3921569 

5.0980392 

XLOAD7 

97 

2.6844552 

13.2715963 

0.3921569 

96.0784314 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 


H0IIR=11 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

101 

6.4453504 

11.2357446 

0.3921569 

87.4509804 

XLOAD4 

101 

39.3321685 

22.2867644 

0.3921569 

98.0392157 

XLOAD5 

101 

0.7843137 

0.7145438 

0.3921569 

3.9215686 

XLOAD7 

101 

1.9180742 

10.4043437 

0.3921569 

98.0392157 

XLOADF 

101 

0.3921569 

0 

0.3921569 

0.3921569 


•H0UR=12- 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

113 

7.5585632 

15.9368336 

0.3921569 

94.5098039 

XLOAD4 

113 

40.5760888 

22.9887743 

5.0980392 

100.0000000 

XLOAD5 

113 

0.9300711 

0.8138600 

0.3921569 

3.5294118 

XLOAD7 

113 

2.8318584 

10.9078404 

0.3921569 

83.9215686 

XLOADF 

113 

0.3921569 

0 

0.3921569 

0.3921569 


-H0UR=13- 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

102 

8.6543637 

14.9578756 

0.3921569 

85.4901961 

XLOAD4 

102 

46.1707036 

22.7281500 

1.5686275 

96.0784314 

XLOAD5 

102 

1.2379854 

1.2629150 

0.3921569 

6.2745098 

XLOAD7 

102 

1.3341023 

3.8098071 

0.3921569 

30.1960784 

XLOADF 

102 

0.3921569 

0 

0.3921569 

0.3921569 
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-HOl]R=14- 

Variable N Mean Std Dev Nfinimum Maximum 


XLOADl 100 7.4235294 11.9424423 0.3921569 71.3725490 

XLOAD4 100 48.9764706 24.2141660 1.5686275 96.0784314 

XLOAD5 100 1.4784314 2.2266601 0.3921569 14.9019608 

XLOAD7 100 0.5843137 0.3999814 0.3921569 2.3529412 

XLOADF 100 0.3921569 0 0.3921569 0.3921569 


HOUR=15 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximmn 

XLOADl 

99 

9.4236482 

16.3475515 

0.3921569 

94.5098039 

XLOAD4 

99 

44.7969895 

21.5666504 

0.3921569 

94.5098039 

XLOAD5 

99 

1.3586849 

1.4406728 

0.3921569 

8.6274510 

XLOAD7 

99 

0.7803525 

0.7250411 

0.3921569 

3.5294118 

XLOADF 

99 

0.3921569 

0 

0.3921569 

0.3921569 


HOUR=16 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

101 

5.5523199 

9.2353953 

0.3921569 

47.8431373 

XLOAD4 

101 

37.5965832 

24.2683107 

0.3921569 

96.0784314 

XLOAD5 

101 

0.9318579 

1.2436400 

0.3921569 

8.6274510 

XLOAD7 

101 

0.6328868 

0.4330459 

0.3921569 

1.9607843 

XLOADF 

101 

0.3921569 

0 

0.3921569 

0.3921569 


-HOUR=17 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

99 

1.9172113 

5.3976330 

0.3921569 

49.8039216 

XLOAD4 

99 

34.6326005 

23.4261203 

0.3921569 

98.0392157 

XLOAD5 

99 

0.5228758 

0.5042017 

0.3921569 

3.5294118 

XLOAD7 

99 

0.5466429 

0.8566451 

0.3921569 

8.6274510 

XLOADF 

99 

0.3921569 

0 

0.3921569 

0.3921569 


HOUR=18- 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

96 

1.2050654 

1.4752878 

0.3921569 

7.0588235 

XLOAD4 

96 

33.4395425 

23.1331251 

0.3921569 

92.5490196 

XLOAD5 

96 

0.5106209 

0.5093108 

0.3921569 

4.7058824 

XLOAD7 

96 

0.4289216 

0.2351436 

0.3921569 

2.3529412 

XLOADF 

96 

0.3921569 

0 

0.3921569 

0.3921569 
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H0UR=19 


Variable 

N 

Mean 

StdDev 

Minimiim 

Maximum 

XLOADl 

95 

1.6676987 

6.9989975 

0.3921569 

67.8431373 

XLOAD4 

95 

30.8400413 

23.5487972 

0.3921569 

92.5490196 

XLOAD5 

95 

0.4293086 

0.1723069 

0.3921569 

1.5686275 

XLOAD7 

95 

0.4458204 

0.2467688 

0.3921569 

1.9607843 

XLOADF 

95 

0.3921569 

0 

0.3921569 

0.3921569 


-HOUR=20 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

96 

0.9477124 

1.7104766 

0.3921569 

15.6862745 

XLOAD4 

96 

26.7687908 

21.3291325 

0.3921569 

92.5490196 

XLOAD5 

96 

0.4330065 

0.2574952 

0.3921569 

2.7450980 

XLOAD7 

96 

0.4207516 

0.1730062 

0.3921569 

1.5686275 

XLOADF 

96 

0.3921569 

0 

0.3921569 

0.3921569 

UrUTD— 




^xx. - 



Vari^le 

N 

Mean 

StdDev 

Minimum 

Maximum 

XLOADl 

97 

0.7196281 

0.6878609 

0.3921569 

3.5294118 

XLOAD4 

97 

25.9874672 

21.1939769 

0.3921569 

92.5490196 

XLOAD5 

97 

0.4244997 

0.3185400 

0.3921569 

3.5294118 

XLOAD7 

97 

0.4204568 

0.1721272 

0.3921569 

1.5686275 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 

XiniTD—00 




x^xx. — 



Variable 

N 

Mean 

StdDev 

Minimum 

Maximum 

XLOADl 

97 

0.7236709 

0.7643291 

0.3921569 

5.0980392 

XLOAD4 

97 

21.9041844 

21.2156946 

0.3921569 

94.5098039 

XLOAD5 

97 

0.3921569 

0 

0.3921569 

0.3921569 

XLOAD7 

97 

0.4164140 

0.1680492 

0.3921569 

1.5686275 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

XLOADl 

97 

1.0632707 

1.1047861 

0.3921569 

5.0980392 

XLOAD4 

97 

18.3828583 

20.1126408 

0.3921569 

76.4705882 

XLOAD5 

97 

0.3921569 

0 

0.3921569 

0.3921569 

XLOAD7 

97 

0.4244997 

0.1760171 

0.3921569 

1.5686275 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 
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APPENDIX E. CURRENT TECHNOLOGIES 


Chapter Vn mentioned some of the services that are currently offered by local and 
national service providers. This Appendix introduces a few of those technologies, and is 
intended to familiarize the reader with a few of the alternative solutions currently available 
in the marketplace. As mentioned in Chapter Vn, those organizations that fall behind the 
technology curve will not only loose their competitive advantage, but the productivity, 
efficiency, and effectiveness of their organizations will also be in jeopardy. The pros and 
cons of these technologies are varied. Be sure to investigate all available alternatives 
thoroughly before investing in any one particular service. 

A. INTEGRATED SERVICES DIGITAL NETWORK (ISDN) 

ISDN is described as a high speed, low cost, all digital dialup telephone service 
delivered to both businesses and homes over standard copper wires. ISDN maximizes the 
transmission capability of existing copper wires, allowing the simultaneous transmission of 
voice, data, and video over a single twisted pair connection [Ref 27]. This technology 
was thought to be the great, new, all digital technology that would replace the plain old 
telephone system (POTS). 

The basic unit of switching for ISDN is a 64-Kbps B-charmel. A separate 16-Kbps 
D-channel is provided as a control channel. The main problem with ISDN’s B-channel is 
that it is becoming increasingly inadequate for many subscribers who are using high- 
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powered workstations and graphics and image processing applications [Ref. 28], Some of 
the characteristics of ISDN include: [Ref 29] 


• Fast connection time. 

• High bandwidth. 

• End-to-end digital connection. 

• Supports voice, data, and video on a single line. 

• May be circuit-switched, packet-switched, or semi-permanently connected. 

• Physically, it is a twisted pair wire. 

• Available in two rates: 

1. Basic Rate Interface (BRI) - 2B + D for 144 Kbps. 

2. Primary Rate Interface (PM) - 23B + D for 1.536 Mbps. 

Those organizations looking to support a WWW server and MPEG video should look into 
the ISDN PRI line, which has a rate similar a T-1 link. The ISDN PRI link is reportedly 
less expensive than a T-1, but for accurate pricing information, interested parties should 
consult with their local telecommunications providers. 


B. FRAME RELAY 

The frame relay standard defines an interface between a user device and a network. 
It is a streamlined version of X.25 packet switching, designed to increase speed by 
drastically reducing the amount of processing time in data transfer mode. Frame relay 
eliminates the Level-3 processing (the packet level or Network Layer in X.25), and 
discards frame sequencing and error recovery at the frame level (Layer 2 in the OSI 
model). [Ref 30] 

Frames are received by the network over a frame relay interface and forwarded 
hop-by-hop from source node to destination node. This operation is very similar to the 
forwarding of packets in virtual circuit-based packet switching networks. The main 



difference is that sequence number checking and retransmissions due to errors do not get 
retransmitted at any step along the way. Frames with errors (detected by frame checking 
sequences) are simply discarded . This hop-by-hop forwarding of frames is called frame 
relay. The main advantage of frame relay is the high speed physical medium (interface) 
with statistical multiplexing to combine multiple channels. [Ref 30] 

Frame relay transfers information in variable length packets (frames), and can 
contain thousands of b)i:es of data. The amount of overhead needed to transmit data 
through frame relay is inherently lower than the overhead required for Asynchronous 
Transfer Mode (ATM), which is discussed in the next section. Some of the characteristics 
of ISDN include; [Ref 31] 

• Requires five bytes of header information for transmission through network. 

• Percentage of bandwidth devoted to overhead varies according to the size of 
the frame. 

• Delay characteristics make it less appropriate for carrying real-time multimedia 
applications such as video teleconferencing. 

• Operates at very high speeds, accommodating large amounts of data with very 
low delay. 

• Provides highly efficient resource sharing by supporting many virtual channels 
over a high speed line. 

• Typical line sizes range from 56-Kbps to T-l/E-1 (1.544/2.048 Mbps). 

• Unpredictable due to the variable length packets, which cause confusion for the 
switches and transmission equipment; they do not know exactly where each 
cell ends and the next one begins. 

• Similar to X.25, except all circuits are permanently assigned. 

• Relies on the customer equipment to perform end-to-end error correction. 

Visit URL http;//www.dcnet.com/notes/framerly.html for a very good overview of Frame 
Relay terms, or try URL http://www.kalpana.com/warp/public/732/Frame/fratm_wp.htm 
to compare Frame Relay and ATM WAN technologies. 
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C ASYNCHRONOUS TRANSFER MODE (ATM) 

ATM is an internationally accepted high-performance multiplexing and switching 
technology that is touted to be the multi-media communications technology that will take 
us into the next generation. ATM protocols are designed to handle isochronous (time 
critical) data such as video and audio, along with the more traditional data 
communications between computers. [Ref 32] 

The interest in ATM has grown out of the need for a worldwide standard to allow 
interoperability of information. The goal of ATM is to provide one international standard. 
Hstorically, there have been several methods used for the transmission of information 
between users. ATM is a method that can be used interchangeably for all traffic types, 
regardless of whether the data is transmitted over a LAN, WAN, or MAN. The goal is to 
close the gap between the various network types, making the transmission of data between 
them seamless to the end users based on one standard system - ATM. [Ref 33] 

The following set of User-Network Interfaces has been prescribed by the ATM 
Forum: [Ref 29] 

• DS-3 (45 Mbps). 

• OC-1 (51 Mbps). 

• TAXI (100 Mbps and 140 Mbps over multimode fiber). 

• OC3c (155 Mbps). 

• OC-48 (2.488 Gbps). 

Some of the characteristics of ATM include: [Ref. 31] 

• Fixed length packets (cells). 

- payload (48 bytes) carries actual information. 

- header (5 bytes) is the addressing mechanism. 



• Smaller, fixed-length cells results in much higher overhead than Frame Relay, 
but offers two advantages over Frame Relay: 

1. Speed - easier to process, since the switching and transmission 
equipment know exactly where each cell ends and the next one begins. 

2. Small cells with a predictable transmission delay allow for interleaving 
cells that carry delay-sensitive traffic, such as interactive video and 
voice along with data cells. 

• Layered architecture allows voice, video, and data to be mixed over the 
network. 

The layered architecture mentioned above has three lower layers that have been 
established to implement the features of ATM: [Ref 32] 

• The Adaptation Layer - assures the appropriate service characteristics and 
divides all types of data into the 48 byte payload that will make up the ATM 
cell. 

• The ATM Layer - takes the data that is to be sent and adds the 5-byte header 
information that assures the cell is sent along the correct connection. 

• The Physical Layer - defines the electrical characteristics and network 
interfaces. This layer “puts the bits on the wire”.^ 

For more information regarding the ATM Forum, or for more technology, architecture, or 

benefits related information on ATM, try the following URLs, respectively: 

http://www.atmforum.com/atmforum/atm_introduction.html 

http://www.npac.syr.edu/users/dpk/ATM_Knowledgebase/ATM_technology.html. 


D. ASYMMETRICAL DIGITAL SUBSCRIBER LINE (ADSL) 

1. General Information and Features 

ADSL provides the highest access speed possible to the internet today over a 
single copper pair. This technology reportedly achieves near instantaneous home page 
downloads and file transfers fi'om the internet. ADSL allows users, whether in the 

* ATM is not tied to a qwcific of physical transport. 
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business or residential environment, to access the internet at T-1 speeds over traditional 
phone lines. At T-1 speeds, the actual throughput can be up to 50 times faster than the 
typical 28.8 modem, or 12 times faster than a 128-Kbps ISDN coimection. [Ref 34] 

Two companies, Westell and Microsoft, are working together on this new 
transmission technology. Additionally, GTE Telephone Operations, Irving, Texas, and US 
West Interprise Networking Services, Denver, Colorado, are implementing or expanding 
their market trials of ADSL technology. According to GTE, ADSL is capable of 
providing up to 6-Mbps downstream (from the network to the user) and up to 640-Kbps 
upstream (from the user to the network), all over the existing telephone lines. At 4-Mbps, 
200 pages of text can be downloaded in less than one second, and a typical WWW page 
with graphics can be downloaded in less than one-tenth of a second. ADSL also offers the 
user the opportunity to receive data and use their telephone, fax machine, or modem 
simultaneously. [Ref 35] 

This new technology is currently undergoing a six-month trial period, designed to 
test the high speed communications capabilities of ADSL over the existing phone lines. 
Exact prices for this technology are expected to be available at the end of the year. For 
more information regarding uses and applications of ADSL, try visiting the ADSL Forum 
at URL http://www.adsl.com/adsl/home_page.html, or for more information regarding the 
trial test period visit GTE at URL http://wcn.gte.com/adsl. 
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2. ADSL Enhances Healthcare 


The healthcare field can benefit fi'om the ADSL technology in several ways. This 
section outlines a few specific areas that are affected [Ref. 34]. 

<L TelemetUcine 

This live, two-way, interactive video communication allows patients to 
consult physicians at remote locations for specialty care not available in the patient’s area. 
ADSL can deliver this extensive service at fi’action of the cost of fiber based systems, and 
provides the versatility of simultaneous records management, image, and file transfer 
capabilities. 


b. Teleradiology 

Whether you are working in a PC or Unix based environment, ADSL can 
deliver biomedical images of any mode, and size, fi'om point-to-point in seconds. Remote- 
primary diagnoses are now possible in real time with high-quality image resolution that is 
not degraded by the ADSL system. 

c. On-Line Medical Research and Internet Access 

The national Library of Medicine estimates that there are over 4,000 
medical libraries within the U.S., half of which are accessible throughout the internet. 
Many of these libraries employ medical literature and retrieval systems (MEDLARS) for 
on-line information services. Physicians are increasingly turning to these on-line medical 
data uses to diagnose difficult cases, track new developments, lower costs, and shorten 
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hospital stays. ADSL can provide a high speed link to these services to improve overall 
quality of care. 


d. ADSL Healthcare Advantages 

Some of the technological advantages that ADSL offers the healthcare field 


include; 

• Faster response and delivery time in case of emergency care situations. 

• Improved overall patient care through resource sharing and high-speed data 
access. 

• Flexible, transparent point-to-point access increases savings for healthcare 
systems integration’s. 
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